Microsoft Entra IDでパスキー展開を検討している企業にとって、2026年4月16日時点で注目すべき更新は Synced passkeys（同期パスキー） です。結論から言うと、一般ユーザー向けには同期パスキーを使うことで、パスワードレス化と耐フィッシングMFAを大規模に展開しやすくなります。一方で、特権管理者や高保証が必要な業務には、デバイスバインド型パスキーやFIDO2セキュリティキーを組み合わせる設計が現実的です。
Microsoftは2026年3月のMicrosoft Entra更新で、Microsoft Entra IDの新リリースとしてSynced passkeysとPasskey profilesを掲載しました。さらにMicrosoft Learnでは、Synced passkeysを一般提供の認証方法として説明し、組み込みまたはサードパーティのパスキープロバイダーに保存され、ユーザーの複数デバイスで利用できるFIDO2ベースの資格情報だとしています。(TECHCOMMUNITY.MICROSOFT.COM)
Microsoft Entra IDでSynced passkeysが重要になる理由
Synced passkeysが重要なのは、単に「パスキーの種類が増えた」からではありません。企業のIdentity adminやIAM architectが悩んできた、次の3つの課題に直接効くからです。
| 企業展開の課題 | 同期パスキーが効く理由 | 設計上の注意 |
|---|---|---|
| パスキー登録が進まない | ユーザーが普段使う端末の生体認証やPINで登録・利用しやすい | 対象OS、ブラウザ、パスキープロバイダーの対応状況を事前確認する |
| 端末紛失・機種変更でロックアウトしやすい | クラウド同期により、同じプロバイダーにサインインした別端末で利用しやすい | 復旧フローをクラウドプロバイダー任せにせず、Entra側の回復手順も用意する |
| SMSやOTPなどフィッシング可能なMFAを減らしたい | FIDO2ベースで、登録先のサイトやアプリに紐づくためフィッシング耐性が高い | 特権アカウントには、より高保証なデバイスバインド型を優先する |
パスキーは、秘密鍵をユーザー側、公開鍵をサービス側に持つ方式です。Microsoft Entra IDの説明では、パスキーは登録されたWebサイトやアプリでのみ機能し、FIDO2標準、WebAuthn、CTAPを利用するフィッシング耐性のある認証情報として整理されています。(Microsoft Learn)
つまり、攻撃者が偽のMicrosoft 365ログイン画面を用意しても、パスキーはその偽サイトに対して正しく提示されません。SMSコードやワンタイムパスワードのように、ユーザーがだまされて入力してしまうタイプのMFAとは根本的に性質が違います。
同期パスキーとデバイスバインド型パスキーの違い
Microsoft Entra IDでは、大きく分けて Device-bound passkeys と Synced passkeys を扱います。どちらもFIDO2ベースですが、企業での使いどころは同じではありません。
| 項目 | Synced passkeys | Device-bound passkeys |
|---|---|---|
| 秘密鍵の扱い | 暗号化されたキーがパスキープロバイダー経由で同期される | 1台の物理デバイスやセキュリティキー内に保持される |
| 主な例 | Apple iCloud Keychain、Google Password Manager、1Password、Bitwardenなど | FIDO2セキュリティキー、Microsoft Authenticatorのデバイスバインド型パスキーなど |
| ユーザー体験 | 複数デバイスで使いやすく、機種変更にも比較的強い | 持っているデバイス・キーが必要で、紛失時の影響が大きい |
| 管理者の保証 | 利便性は高いが、同期パスキーはattestationをサポートしない | attestationを使えば、登録された認証器のモデル確認に使える |
| 向いている対象 | 一般従業員、営業、バックオフィス、グローバル従業員 | 特権管理者、規制対象業務、重要システム利用者 |
| 主なリスク | 利用するクラウドパスキープロバイダーの管理・復旧ポリシーに依存する | 紛失・故障時の回復コストが高い |
Microsoftのドキュメントでは、同期パスキーはHSMで作成され、ローカルデバイス上で暗号化されたキーがクラウドのパスキープロバイダーに同期されると説明されています。一方で、同期パスキーはattestationをサポートせず、attestationを有効にすると同期パスキーは除外される点に注意が必要です。(Microsoft Learn)
ここで重要なのは、同期パスキーを「弱い」と決めつけないことです。Microsoftは、同期型かデバイスバインド型かにかかわらず、パスキーはフィッシング可能なMFAより大きなセキュリティ向上になると説明しています。ただし、特権アカウントや高規制環境では、FIDO2セキュリティキーなどの高保証な選択肢が推奨されます。(Microsoft Learn)
大規模展開で同期パスキーが現実解になりやすい理由
企業のパスキー展開で失敗しやすいのは、セキュリティ強度だけを見て設計してしまうケースです。認証は毎日使われるため、ユーザー体験が悪いと登録率が伸びず、ヘルプデスク負荷も増えます。
Microsoftは、同期パスキーについて、Microsoftアカウント利用者からの知見として、登録成功率99%、従来のパスワードとMFAの組み合わせより14倍高速、サインイン成功率は同期パスキーが95%で従来方式が30%という数値を示しています。これはすべての企業環境で同じ結果を保証するものではありませんが、認証モダナイゼーションの方向性を判断する材料になります。(Microsoft Learn)
大規模展開で特に効くのは、次の3点です。
ユーザー教育を短くできる
同期パスキーは、顔認証、指紋認証、端末PINなど、ユーザーが日常的に使っている操作に近い体験を提供できます。説明も「コードを入力してください」ではなく、「端末のロック解除と同じ操作でサインインします」に近づけられます。
これはグローバル企業ほど重要です。国や地域ごとにヘルプデスク、言語、端末支給ポリシーが異なる場合、認証手順が複雑だと展開コストが跳ね上がります。同期パスキーは、標準ユーザーに対して展開しやすい現実解になりやすい方式です。
端末紛失時の業務停止を減らせる
デバイスバインド型だけで設計すると、端末故障やセキュリティキー紛失時に、ユーザーが完全にサインインできなくなるケースが増えます。同期パスキーは、パスキープロバイダー側で復元できる設計であれば、別端末から再開しやすい点が利点です。
ただし、ここで「同期されるから回復設計は不要」と考えるのは危険です。企業側では、Temporary Access Pass、本人確認、ヘルプデスク手順、監査ログ確認を含めた復旧フローを用意しておく必要があります。
Passkey profilesで対象者ごとの方針を分けられる
今回の更新で実務上大きいのは、同期パスキーだけではなく Passkey profiles と一緒に考えられる点です。Passkey profilesでは、グループごとにattestation、パスキー種別、AAGUIDによる認証器制限などを定義できます。Microsoftの手順では、Passkey profilesを有効化し、プロファイルを作成し、対象グループに適用し、必要に応じて同期パスキーを有効化する流れが示されています。(Microsoft Learn)
これにより、全社一律ではなく、次のような段階的な設計ができます。
| 対象 | 推奨方針 | 理由 |
|---|---|---|
| 一般従業員 | 同期パスキーを許可 | 登録率、利便性、復旧性のバランスが良い |
| 営業・モバイルワーカー | 同期パスキーを優先し、予備手段を登録 | 複数端末利用や外出先利用が多い |
| 開発者・本番環境アクセス者 | 同期パスキーだけにせず、デバイスバインド型も要求 | 侵害時の影響が大きい |
| IT管理者・特権ロール保持者 | FIDO2セキュリティキーやattestation付きデバイスバインド型を優先 | 高保証と監査性を重視する |
| 役員・秘書室 | 利便性と保護の両立。重要アプリは強い認証を要求 | 標的型攻撃を受けやすい |
Microsoft Entra IDで同期パスキーを有効化する基本手順
実際の設定では、いきなり全ユーザーに有効化するのではなく、パイロットグループから始めるのが安全です。
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 事前確認 | 対象OS、ブラウザ、パスキープロバイダー、既存MFA登録状況を確認 | Apple、Google、サードパーティプロバイダーの利用可否を整理する |
| Passkey profilesを有効化 | Microsoft Entra管理センターでPasskey profilesを有効化 | 有効化後に元へ戻せない点を変更管理に記録する |
| プロファイル作成 | 一般ユーザー向け、管理者向けなどに分けて作成 | 同期型、デバイスバインド型、attestation要件を分ける |
| 対象グループに適用 | パイロットグループから段階展開 | IT部門だけでなく、営業、海外拠点、BYOD利用者も含めて検証する |
| 同期パスキーを有効化 | Passkey typeでSyncedを選択 | 既存のFIDO2設定やセキュリティキー制限と矛盾しないか確認する |
| 条件付きアクセスで強制 | 重要アプリに認証強度を適用 | 最初から全アプリ必須にせず、重要度の高いアプリから始める |
| 復旧手順を整備 | TAP、本人確認、再登録手順を用意 | 端末紛失、UPN変更、退職・再雇用などを想定する |
Microsoft Learnでは、同期パスキーを有効化するにはPasskey profilesが有効であること、Authentication Policy Administrator以上の権限が必要であること、Entra IDのAuthentication methods policyからPasskey (FIDO2)を構成することが示されています。(Microsoft Learn)
また、Passkeys (FIDO2)はMicrosoft Entra ID Freeを含むすべてのMicrosoft Entra IDエディションで利用でき、追加ライセンスは不要と説明されています。一方で、条件付きアクセスでパスワードレスサインインを強制したり、認証方法の利用状況レポートを活用したりするには、Microsoft Entra ID P1相当の機能を前提に計画した方がよい場面があります。(Microsoft Learn)
復旧設計で見るべきポイント
同期パスキーの価値は、登録とサインインだけではありません。企業展開では、むしろ 復旧時にどれだけ安全に戻せるか が重要です。
SSPRとAccount Recoveryを混同しない
Self-Service Password Reset（SSPR）は、ユーザーが登録済みの認証方法を使える前提でパスワードをリセットする仕組みです。一方、Microsoft Entra ID Account Recoveryは、すべての認証方法を失ったような完全ロックアウト時に、本人性を再確認して信頼を再確立する考え方です。MicrosoftはAccount Recoveryについて、従来のパスワードリセットではなく、ユーザーIDの検証と信頼の再確立に重点を置く仕組みと説明しています。(Microsoft Learn)
| シナリオ | 使うべき手段 | 補足 |
|---|---|---|
| パスワードを忘れたがMFAは使える | SSPR | 既存の認証方法で本人確認できる |
| スマートフォンを紛失したが別端末でパスキーが使える | 同期パスキーで継続利用 | ただし端末紛失時のリスク評価は必要 |
| すべての認証方法を失った | Account Recoveryや本人確認済みTAP | ヘルプデスクの口頭確認だけに頼らない |
| 認証方法が悪意を持って変更された疑い | 既存方法を信頼せず再登録 | Zero Trustの復旧手順として扱う |
認証方法の復旧は「事故」と「侵害」で分ける
Microsoft Entra Backup and Recoveryのドキュメントでは、認証方法の変更や削除が偶発的なものか、悪意あるものかで復旧姿勢を分ける考え方が示されています。偶発的な変更では復元と検証を行い、悪意ある変更では既存方法を信頼せず、新しい認証方法を再登録する流れが示されています。(Microsoft Learn)
特に注目すべきは、復元後に利用可能な認証方法の一覧にSynced passkeyも含まれている点です。ただし、Backup and Recoveryはプレビュー機能として説明されているため、本番設計では利用条件、サポート範囲、法務・監査要件を必ず確認してください。(Microsoft Learn)
失敗しやすい設計パターン
全員に同じパスキー方針を適用してしまう
一般ユーザーにとって最適な方式と、特権管理者にとって最適な方式は違います。同期パスキーは大規模展開に向いていますが、attestationを使ったデバイス保証が必要な領域には向きません。
特権管理者、PIM対象者、グローバル管理者、セキュリティ管理者には、FIDO2セキュリティキー、Microsoft Authenticatorのデバイスバインド型パスキー、証明書ベース認証などを組み合わせ、条件付きアクセスの認証強度で制御する設計が望ましいです。
「同期＝企業が完全に管理できる」と誤解する
同期パスキーは、Apple、Google、1Password、Bitwardenなどのプロバイダー側の仕組みに依存します。BYODを許可する場合、企業が端末、OS、ブラウザ拡張、個人用クラウドアカウントの状態をどこまで管理できるかは限定されます。
そのため、利用を許可するプロバイダー、対象デバイス、紛失時の報告手順、退職時の扱いを明文化する必要があります。特にグローバル企業では、国ごとの個人端末利用ルールやプライバシー規制にも注意が必要です。
復旧手順をヘルプデスク任せにする
パスワードレス化が進むほど、本人確認を誤った場合の影響は大きくなります。ヘルプデスクが「社員番号」「上長名」「最近のチケット番号」だけで認証方法をリセットする運用は、ソーシャルエンジニアリングの標的になります。
復旧時は、少なくとも次の情報を運用手順に含めるべきです。
| 項目 | 確認内容 |
|---|---|
| 本人確認 | Verified ID、Face Check、IDV、社内承認、対面確認など、組織に合う方法を決める |
| 発行する一時手段 | TAPを使う場合は有効期限、利用回数、発行者権限を制限する |
| ログ確認 | Audit logs、Sign-in logs、認証方法の変更履歴を確認する |
| 再登録 | 古い認証方法を削除し、信頼できる端末から再登録させる |
| 事後対応 | 侵害疑いがあればセッション失効、パスワード変更、リスク調査を行う |
Microsoftのパスワードレス展開ガイドでも、リモートユーザーや新入社員のオンボーディングでは本人確認後にTemporary Access Passを発行し、最初のポータブル資格情報を登録させる流れが説明されています。(Microsoft Learn)
導入前に確認すべき制限と注意点
同期パスキーは便利ですが、事前に確認すべき制限があります。ここを見落とすと、パイロットでは成功しても全社展開でつまずきます。
| 確認項目 | 注意点 |
|---|---|
| attestation | 同期パスキーはattestationをサポートしない。高保証が必要な対象には別方式を検討する |
| 対応環境 | Apple Passwords、Google Password Manager、サードパーティプロバイダーで対応OSやブラウザ要件が異なる |
| ゲストユーザー | Microsoftの既知の問題として、内部・外部ゲストユーザーのパスキー登録はサポートされないと説明されている |
| UPN変更 | UPNが変わると既存パスキーを変更できず、ユーザーが古いパスキーを削除して新しく追加する必要がある |
| プロファイル削除 | 対象グループに割り当てられているプロファイルは削除できない |
| 同期パスキー無効化 | 既に登録済みでも、対象プロファイルで同期パスキーを無効化するとサインインできない |
これらの制限は、Microsoft Learnの有効化手順と既知の問題に記載されています。特にUPN変更とゲストユーザーの扱いは、M&A、組織再編、外部協力会社のアクセス管理で影響が出やすいポイントです。(Microsoft Learn)
実務で使える展開モデル
最初から「全社パスワードレス」を目標にすると、設計が重くなりすぎます。おすすめは、以下のような3段階モデルです。
第1段階: 一般ユーザー向けに同期パスキーを試す
最初は、ITリテラシーが高すぎない部署も含めて小さく開始します。IT部門だけで試すと、実際の問い合わせや説明のつまずきが見えません。
対象例としては、営業、管理部門、海外拠点の一部などが向いています。確認すべき指標は、登録完了率、登録にかかった時間、サインイン成功率、ヘルプデスク問い合わせ数です。
第2段階: 重要アプリに認証強度を適用する
登録が進んだら、Microsoft 365、VPN代替、SaaS、社内ポータルなどの重要アプリに対して、条件付きアクセスでフィッシング耐性のある認証を求めます。
このとき、いきなり全リソースに強制しないことが重要です。役員、営業、海外拠点、モバイル利用者など、業務停止の影響が大きいグループには例外設計と復旧手順を先に用意します。
第3段階: 特権アカウントを別ポリシーに分離する
標準ユーザーの成功体験を確認した後、特権アカウントは別ポリシーで強化します。
特権管理者には、同期パスキーだけでなく、FIDO2セキュリティキー、デバイスバインド型パスキー、証明書ベース認証などを組み合わせます。条件付きアクセス、PIM、サインインリスク、管理端末の準拠状態を合わせて評価することで、単なる「MFA導入」ではなく、実効性のある認証モダナイゼーションになります。
導入後に見るべきKPI
パスキー展開の成功は、「有効化したか」では判断できません。運用後は、次のKPIを継続的に確認します。
| KPI | 見る理由 |
|---|---|
| パスキー登録率 | 展開対象に対して、実際に使える状態になっているかを確認する |
| サインイン成功率 | ユーザー体験が悪くないかを判断する |
| SMS・音声通話MFAの利用率 | フィッシング可能な手段をどれだけ減らせたかを見る |
| TAP発行件数 | 復旧フローが過剰に発生していないかを確認する |
| 認証方法リセット件数 | ヘルプデスク負荷や不正リセットリスクを把握する |
| 条件付きアクセス失敗件数 | ポリシーが厳しすぎて業務影響を出していないかを見る |
| 特権アカウントの強認証適用率 | 最も守るべき対象が保護されているかを確認する |
特に、SMSやOTPの利用率が下がらない場合は、ユーザーがパスキーを登録していても実際のサインインでは古い方法を使っている可能性があります。条件付きアクセスと認証強度を使い、段階的にフィッシング耐性のある方法へ誘導する必要があります。
企業が次に取るべきアクション
Microsoft Entra IDのSynced passkeysは、パスワードレスと耐フィッシングMFAを「一部の高セキュリティユーザーだけのもの」から「全社展開できる現実的な認証方式」へ近づける更新です。
ただし、同期パスキーを有効化するだけでは十分ではありません。一般ユーザーには同期パスキーで利便性と普及率を高め、特権ユーザーにはデバイスバインド型やFIDO2セキュリティキーで保証レベルを上げる。さらに、端末紛失や完全ロックアウトに備えたAccount Recovery、TAP、監査ログ確認の手順まで整えて初めて、企業向けの認証モダナイゼーションとして機能します。
まずは、一般ユーザー向けのPasskey profileと特権ユーザー向けのPasskey profileを分けて設計し、20〜50人程度のパイロットで登録率、サインイン成功率、問い合わせ内容を測定してください。その結果をもとに、条件付きアクセスで重要アプリから段階的にフィッシング耐性のある認証を求める流れが、最も失敗しにくい進め方です。
コメント