こんにちは。ネクストモードのゆきなわです。
パスワードに代わる認証手段としてパスキー (Passkeys) の普及が進んでいます。FIDO Alliance が開始した The Passkey Pledge には Okta を含む多くの企業が参加しており、業界全体でパスワードレス化の取り組みが広がっています。Okta Identity Engine (OIE) でもパスキーによる認証がサポートされており、フィッシング耐性のある認証を実現できます。
しかし、いざ導入しようとすると「管理画面にパスキー設定がないけどどこから設定できる？」「証明書利用者 ID って何？設定した方がいい？」「ポリシーはどう設定すればいい？」「特定のユーザーに特定の同期パスキーのみ利用を許可できる？」といった、さまざまな疑問や課題に直面することも事実です。また、Okta において機能的に重複する Okta FastPass との使い分けも課題になります。
なお、パスキーの導入自体が自社にとって適切かどうか（Okta FastPass やセキュリティキーとの優先度判断を含む）については、以下の記事で整理していますので、本質的な導入判断の部分で迷われている方はぜひお読みください。
本記事では、主に、パスキーを導入すると決めた方、あるいは条件付きで導入を検討している方を対象に、導入前に決めておくべき設計判断、Okta FastPass との使い分け、公式ドキュメントだけではカバーしきれない運用上の注意点も含めて体系的にご紹介します。
※本記事は2026年2月時点の情報に基づいて作成しています。最新情報は公式ドキュメントをご確認ください。
本記事は内容が多岐にわたるため、目的に応じて以下のように読み進めていただくと効率的です。
| 読者の目的 | 推奨セクション |
|---|---|
| パスキーを導入すべきか判断したい | 別記事【Okta】企業で Passkey はアリ？ナシ？採用前に整理したい判断ポイントをお読みください |
| パスキーの基礎から理解したい | セクション3〜4で基礎知識と Okta 上の用語を確認 |
| 導入前に何を決めておくべきか知りたい | セクション5で設計判断のポイントを確認 |
| Okta FastPass との違い・使い分けを知りたい | セクション6で両者の比較と併用方針を確認 |
| 設定手順を確認したい | セクション7の管理者設定ガイドへ直行 |
| ユーザーへの展開方法を知りたい | セクション8で登録・認証フローを確認 |
| 運用で気をつけるべき落とし穴を知りたい | セクション9で注意点を確認 |
| 個別の疑問を解消したい | セクション10の FAQ を参照 |
Okta で初めてパスキーを導入する方は、セクション3から順にお読みいただくことで、基礎知識の理解から設計判断、設定手順、運用上の注意点まで一貫して把握できます。すでに基礎知識をお持ちの方は、セクション5（設計判断）またはセクション7（設定手順）から読み始めていただくのがおすすめです。
パスキーは FIDO2 / WebAuthn 標準に基づく認証方式です。パスワードの代わりに、デバイスに保存された暗号鍵ペア（公開鍵・秘密鍵）を使って認証を行います。従来のパスワード認証がサーバーに秘密情報を送信するのに対し、パスキーではクライアント側で認証を行い、サーバーには署名付きの認証データ (authenticatorData / clientDataJSON / signature など) が送信されます。
Okta では FIDO2 (WebAuthn) Authenticator としてパスキーがサポートされています。
パスキーには同期パスキーとデバイス固定パスキーの2種類があります。Okta では同期パスキーのブロックが可能であり、後続の同期パスキーを許可するか・ブロックするかの運用設計の判断が必要となります。
| 種類 | 説明 | 例 |
|---|---|---|
| 同期パスキー (Synced Passkey) | クラウド経由で複数デバイス間に同期されます | iCloud キーチェーン、Google パスワードマネージャー、パスワードマネージャー (Keeper 等) |
| デバイスバウンド（固定）パスキー (Device-bound Passkey) | 特定のデバイスにのみ保存され、エクスポートできません | Windows Hello や YubiKey などの FIDO2 セキュリティキー |
両者の違いは、次の設計項目に影響します。
ヒント: どのパスキー基盤（Authenticator とパスキープロバイダーの組み合わせ）を許可するかの設計については、セクション 5-2 で詳しく解説します。
Okta では管理画面・サインイン画面における Authenticator 選択の際、「パスキー」という言葉がダイレクトには出てきません。そのため、初期導入時に管理者・ユーザーともに混乱を招くケースがあります。ここでは Okta 上のパスキー関連用語を整理します。
| Okta の画面上の用語・設定項目 | 場所 | 対応する技術用語・説明 |
|---|---|---|
| FIDO2 (WebAuthn) | Authenticator 一覧 | FIDO2 / WebAuthn 標準に基づく Authenticator。パスキーはこちらに内包されています |
| セキュリティキーまたは生体認証Authenticator (Security Key or Biometric Authenticator) | サインイン画面 (Sign-In Widget) | サインイン画面で表示される Authenticator の名称。パスキーで認証する際に選択します |
| フィッシング耐性 (Phishing resistant) | 認証ポリシーの制約条件 | FIDO2 (WebAuthn) または Okta FastPass が条件を満たします |
| 同期パスキーのブロック (Block synced passkeys) | FIDO2 Authenticator の設定 | 同期パスキーの新規登録をブロックする設定 |
| ハードウェア保護 (Hardware protection) | 認証ポリシーの制約条件 | 秘密鍵が TPM や Secure Enclave に保存されていることを要求。同期/デバイス固定とは別軸の概念※ |
※重要: パスキーの同期不可とハードウェア保護は必ずしも同義ではない点に注意が必要です。 例えば、iPhone の Secure Enclave で保護されたパスキーは、ハードウェア保護の要件を満たしつつも、iCloud キーチェーン経由で別デバイスに同期される場合があります。そのため、ハードウェアによる保護の有無と同期の可否は、それぞれ独立した概念として整理して理解する必要があります。
【Okta】企業で Passkey はアリ？ナシ？採用前に整理したい判断ポイントでも触れいていますが、現在、Okta では FIDO2 (WebAuthn) Authenticator が パスキー Passkeys (FIDO2 WebAuthn) へリブランドされる動きが進んでいます。この変更では、管理者向けの設定ページが統合・簡素化されるほか、Authenticator の表示名をカスタマイズできる機能や、サインイン画面 (Sign-In Widget) に専用のパスキーでサインイン (Sign in with a passkey) ボタンが追加されるなどの UX 改善が含まれる予定です。
これにより、現行のセキュリティキーまたは生体認証 Authenticator という表記で分かりにくかったパスキーの選択が、ユーザーにとってより直感的になることが期待されます。今後 GA（一般提供）になった際には、本記事で取り上げた「管理画面にパスキー設定が見当たらない」といった課題も大幅に解消される見通しです。
本機能は2026年2月にプレビューから早期アクセス (Early Access; EA) に変わった段階です。最新の状況は公式ドキュメントをご確認ください。
パスキーの導入に先立ち、以下の設計項目を確定することが重要です。設定後に変更すると大きな手戻りが発生する項目が含まれています。全体の大まかな流れを下図に示します。
証明書利用者 ID (Relying Party ID; RP ID) はパスキーの認証スコープを定義するドメイン識別子です。FIDO2 クレデンシャル（パスキー）は RP ID に紐づいて作成されるため、RP ID を変更すると、新しい RP ID のスコープ外となる既存のパスキーは利用できなくなります。
Okta のデフォルト設定では Okta org のドメイン（例: yourcompany.okta.com）が使用されますが、カスタムドメイン（例: login.yourcompany.co.jp）にも変更可能です。
デフォルトの okta.com サブドメインを使うと、将来別の IdP 環境に移行する際に全ユーザーの再登録が必要となり、運用負荷が大きくなるケースがあります。FIDO2 の仕様では、パスキーは RP ID（ドメイン）に公開鍵暗号で結び付けられているため、ドメインの変更時は既存クレデンシャルは利用できなくなります。
| RP ID の設定 | メリット | 課題 |
|---|---|---|
| デフォルト （ yourcompany.okta.com） |
設定が簡単、DNS 検証不要 | IdP 移行時に再登録が必要 |
| カスタムドメイン （ login.yourcompany.co.jp） |
自社ドメインでパスキーを管理でき、IdP 移行時の柔軟性を確保 | 事前に別途カスタムドメインの追加が必要です |
組織でカスタムドメインを含む複数の Okta org URL（例: yourcompany.okta.com と login.yourcompany.co.jp と yourcompany-sub.okta.com）を使い分けている場合、FIDO2 (WebAuthn) Authenticator は追加した org URL からのみアクセスできます。複数の org URL でパスキーを利用するには、それぞれの org URL ごとに FIDO2 Authenticator を追加する必要があります。
パスキーを導入する際は、どのパスキー基盤（Authenticator とパスキープロバイダーの組み合わせ）を許可するかを検討する必要があります。
パスキーの利用には、認証処理（鍵ペアの生成・署名・ユーザー検証）を行う Authenticator（認証器） と、パスキーの保管・同期を担うパスキープロバイダー（クレデンシャルマネージャー） が関わります。多くの場合、この2つは一体で提供されます。
以下の表に、主要なパスキー基盤とその特徴をまとめます。
| パスキー基盤 | Authenticator | パスキープロバイダー | パスキーの同期 | 主な対応プラットフォーム |
|---|---|---|---|---|
| iCloud キーチェーン / Apple Passwords (パスワード) | Touch ID / Face ID（プラットフォーム） | iCloud キーチェーン | 同期（Apple デバイス間、iCloud 経由） | iOS、iPadOS、macOS |
| Google パスワードマネージャー | Android 生体認証（プラットフォーム） | Google パスワードマネージャー | 同期（Google アカウント経由） | Android、Chrome（マルチプラットフォーム） |
| Chrome プロファイル (Chrome on Mac) | Touch ID（プラットフォーム） | Chrome プロファイル chrome://settings/passkeys から確認可能 |
デバイス固定 | macOS のみ |
| Windows Hello | Windows Hello（プラットフォーム） | Windows Hello（TPM） | デバイス固定 ※1 | Windows 10 / 11 |
| YubiKey 等のセキュリティキー（物理キー） | セキュリティキー（ローミング） | セキュリティキー本体 | デバイス固定 | クロスプラットフォーム（USB / NFC） |
| Keeper、1Password 等のパスワードマネージャー | プラットフォーム Authenticator ※2 | 各サービスのクラウド | 同期（マルチプラットフォーム） | Windows、macOS、iOS、Android、主要ブラウザ |
※1 Windows Hello は原則としてデバイス (TPM) に鍵を固定しますが、個人用 Microsoft アカウントなど設定によっては同期機能を利用できる場合があります。企業利用 (Windows Hello for Business) では一般的にデバイス固定となります。
※2 サードパーティのパスキープロバイダーは、OS のクレデンシャルプロバイダー API を通じてプラットフォーム Authenticator のユーザー検証を利用しつつ、鍵の保管・同期を独自に行います。
他のパスキー基盤では Authenticator とプロバイダーが一体ですが、サードパーティプロバイダーでは両者が分離しており、OS に依存しないマルチプラットフォームでのパスキー同期が可能になります。利用には OS 側のクレデンシャルプロバイダー API 対応が前提となります（iOS 17 以降、Android 14 以降、macOS Sonoma 以降など）。
どのパスキー基盤を許可するかは、Okta 上では主に以下の 2 つの方法で制御します。
| 制御方法 | 制御の粒度 | 適するケース |
|---|---|---|
| 同期パスキーのブロック | 同期パスキーを作成する既知のプロバイダーを一括でブロック | 同期パスキーを全面的に禁止し、デバイス固定パスキーのみを許可したい場合 |
| Authenticator グループ（AAGUID ベース） | 特定のパスキー基盤を個別に許可・ブロック | Keeper など特定のプロバイダーのみを許可したい場合。本番適用には実機検証で期待どおりに識別できることを確認してください |
同期パスキーのブロックを有効にすると、iCloud キーチェーン、Keeper を含む同期パスキー全般がブロック対象になります。特定の同期パスキープロバイダーのみを許可したい場合は、「同期パスキーのブロック」は使用せず、Authenticator グループで許可する Authenticator Attestation Global Unique Identifier (AAGUID) を明示的に指定するホワイトリスト方式を採用してください。
| 検討項目 | 考慮すべきポイント |
|---|---|
| 対象ユーザーのデバイス構成 | 社内管理端末が中心か、BYOD が多いか。プラットフォーム Authenticator の可用性は端末スペックに依存することがある |
| セキュリティ要件 | 高セキュリティ環境ではセキュリティキー（YubiKey など）の利用を必須としたい場合がある |
| コストと配布負荷 | 物理セキュリティキーは購入・配布・管理の運用コストが発生する。プラットフォーム Authenticator であれば追加コスト不要 |
| クロスプラットフォームの要件 | ユーザーが複数 OS を跨いで利用する場合、OS 標準のパスキー基盤ではエコシステム間の同期に制約がある。Keeper 等のサードパーティプロバイダーを採用することで、OS に依存しないパスキー管理が可能になる |
| 既存ツールとの整合性 | 組織で既にパスワードマネージャーを導入している場合、そのツールのパスキー対応状況を確認し、運用を統合できるか検討する |
| AAGUID による制限の要否 | 特定のパスキー基盤のみに限定したい場合は、Authenticator グループと AAGUID リストを活用する（セクション 7-3 で設定手順を解説） |
例えば、以下のような方針が考えられます。
どのパスキー基盤を許可するかの制御は、Okta の Authenticator グループ機能で実現できます。具体的な設定手順はセクション 7-3 を参照してください。
パスキー導入における重要な設計判断の一つが、同期パスキーを許可するかどうかです。
| 観点 | 同期パスキーを許可する場合 | 同期パスキーをブロックする場合 |
|---|---|---|
| ユーザー体験 | パスキー基盤で同期して、複数デバイスでシームレスに利用可能。CDA によるクロスデバイス認証も活用しやすい | デバイスごとに個別登録が必要 |
| デバイス紛失時のリカバリ | クラウド同期で自動復旧（リカバリ負荷が大幅に軽減） | バックアップ手段がない場合、管理者リセットが必要 |
| セキュリティレベル | クラウドアカウント侵害時のリスクあり | 同期型パスキー由来のリスクを低減（ただし完全な保証ではない） |
| 管理の複雑性 | 低い | 高い（デバイス管理とリカバリ手順の整備が必須） |
| コンプライアンス | セキュリティ要件によっては許容されない場合あり | 高セキュリティ要件に適合しやすい (attestation 検証の併用がより望ましい) |
設定オプション「同期可能なパスキーをブロック (Block synced passkeys)」は、Authenticator の電子署名を検証してブロックする方式 (Attestation) ではありません。Okta は同期パスキーを作成することが既知である Authenticator を識別し、ブロックする方式を採用しています（公式ドキュメントでは “blocks authenticators that are known to create syncable passkeys” と説明されています）。そのため、以下のようなケースが発生する可能性があります。
より厳密な制御（特定の同期プロバイダーのみ許可する等）が必要な場合は、セクション 5-2 で解説した Authenticator グループによる AAGUID ベースのホワイトリスト管理や、証明書ベースの attestation 検証（認証検証、主にセキュリティキーで有効）の併用を検討してください。
パスキー導入時に見落とされがちですが、ユーザーがデバイスを紛失した場合のリカバリフローは事前に設計しておく必要があります。この点は FIDO Alliance でも継続的に議論されている課題です。
| 戦略 | 方法 | 推奨度 |
|---|---|---|
| 複数 Authenticator の事前登録 | スマートフォン + セキュリティキーなど、異なるデバイスで複数のパスキーを登録しておく | ★★★（最も推奨） |
| 同期パスキーの活用 | iCloud キーチェーン、Google パスワードマネージャー、Keeper 等の同期パスキープロバイダーで自動復旧 | ★★★（BYOD 環境で有効） |
| バックアップ Authenticator の併用 | パスキー以外にも Okta Verify 等を登録しておく | ★★☆ |
| 管理者による手動リセット | Admin Console からユーザーの FIDO2 登録をリセットし再登録 | ★☆☆（最終手段。ヘルプデスク負荷・本人確認の精度が課題） |
（重要）管理者リセットをリカバリの主要手段にする場合、「リセット依頼時にどう本人確認を行うか」に関するプロセスを必ず整備してください。
Okta Identity Engine には、フィッシング耐性のある認証方式として FIDO2 (WebAuthn) によるパスキー/セキュリティキーと Okta FastPass (Okta Verify) の 2 つの選択肢があります。どちらもフィッシング耐性を持つ点は共通ですが、それぞれが適するユースケースは異なります。
基本的には、社内管理デバイス（MDM / UEM 配下）なら Okta FastPass、BYOD・社外ユーザーならパスキーとなります。ただし、それぞれは排他的な認証方式ではないため、併用することでより Okta の強みを引き出すことができます。以下で詳しく見ていきます。
| 観点 | パスキー (FIDO2 WebAuthn) | Okta FastPass (Okta Verify) |
|---|---|---|
| 必要な Okta ライセンス | MFA、Adaptive MFA | SSO、MFA、Adaptive MFA |
| フィッシング耐性 | あり | あり |
| 認証方式 | 公開鍵暗号（WebAuthn 標準） | 公開鍵暗号（Okta 独自プロトコル。FIDO 非互換） |
| 追加アプリのインストール | 不要（ブラウザ標準機能） | Okta Verify アプリが必要 |
| デバイスシグナルの収集 | 不可 | 可能（OS バージョン、セキュリティパッチ、スクリーンロック状態など）※ |
| デバイス保証ポリシー | パスキー単体では利用不可 | 利用可能（デバイスの健全性を認証条件に組み込める）※ |
| 管理デバイス判定 | 不可 | 可能（MDM 連携）※ |
| サイレント認証 | 不可 | 可能（バックグラウンドで自動認証） |
| クロスデバイス認証 (CDA) | 可能（QR コードを使って別デバイスで認証） | デバイスごとに Okta Verify の登録が必要 |
| 対応プラットフォーム | WebAuthn 対応の主要ブラウザ全般（ChromeOS や Linux を含む） | Windows、macOS、iOS、Android（Linux / ChromeOS は非対応） |
| FIDO 標準準拠 | FIDO2 / WebAuthn 準拠 | FIDO 非互換（Okta 独自） |
※ 利用には Adaptive MFA ライセンスの契約が必要です。
実際の運用では、パスキーと Okta FastPass は必ずしも排他的ではなく、併用することでカバー範囲を強化することもできます。
| 対象ユーザー/デバイス | 推奨する認証手段 | 理由 |
|---|---|---|
| 社内管理デバイス (PC) | Okta FastPass | デバイスシグナル収集によるきめ細かなアクセス制御、サイレント認証によるUX 向上が可能 |
| BYOD / アプリ導入制限のある端末 | パスキー | 追加アプリ不要でフィッシング耐性を確保 |
| ChromeOS / Linux 端末 | パスキー | Okta FastPass が非対応のため唯一の選択肢 |
| 高セキュリティ業務（特権アクセス等） | Okta FastPass（デバイス保証） + FIDO2 セキュリティキー | デバイスポスチャーチェック + 物理キーの二重保護 |
| 外部パートナー / 協力会社 | パスキー | MDM 管理外でも導入可能 |
| B2B / B2C 顧客（顧客認証基盤として Okta を利用） | パスキー | 顧客に提供する自社サービスの認証用途で有力な選択肢 |
認証ポリシー側では、所有要素の制約でフィッシング耐性を指定すれば、FIDO2 (WebAuthn) と Okta FastPass のどちらでも条件を満たせます。このようにユーザーの環境に応じて柔軟に使い分けられるのが併用の最大のメリットです。
補足: Okta FastPass は FIDO 標準とは互換性がありません。
そのため、FIDO 標準への準拠が組織の情報セキュリティ要件にある場合は、パスキー/セキュリティキーの利用が唯一の選択肢となります。
ここからは、パスキーを有効にするための設定手順を順を追ってご紹介します。
まず、FIDO2 (WebAuthn) Authenticator を Okta に追加します。
Authenticator 追加時、または Authenticator 一覧で FIDO2 (WebAuthn) の [アクション] > [編集] から、パスキー固有のオプション設定を行うことが可能です。
設定オプションのリリース状況について: 組織やリリース時期によって、機能の表示有無は org ごとに異なります。2026年2月現在、パスキー自動入力 (Passkeys Autofill) と同期パスキーのブロック (Block synced passkeys) は早期アクセス (Early Access; EA) 機能として提供されているため、Admin Console の [設定] > [機能] でステータスを確認し、必要に応じて有効化してください。
ON にすると、ユーザーがサインイン画面のユーザー名フィールドをクリックした際に、登録済みのパスキー候補がブラウザの自動入力として表示する UI が有効化されます。
※パスワードファーストのフロー（最初にパスワード入力を求める認証ポリシー）ではパスキー自動入力は動作しません。また、セキュリティキーは候補に表示されません。
この設定は、主に FIDO2 (WebAuthn) Authenticator の登録時 にユーザー検証 (User Verification) をどう要求するかを定義します。実際の体験はプラットフォーム差があり、OS によっては PIN のセットアップを求められる場合があります。
| 設定値 | 登録時の挙動 |
|---|---|
| 非推奨 (Discouraged) | ユーザー検証を要求しません |
| 推奨 (Preferred) | ユーザー検証対応の Authenticator で検証を要求します。プラットフォームにより PIN セットアップを求められる場合があります |
| 必須 (Required) | 生体認証 / PIN による検証が必須。非対応デバイスでは登録に失敗する場合があります |
多くのケースでは 推奨がバランスの取れた選択肢です。必須は古いセキュリティキーなど一部のデバイスで登録失敗の原因になる可能性があるため、対象とするデバイスを事前に確認してください。
注意: ブラウザや Authenticator の組み合わせによっては、この設定が期待通りに適用されないケースがあります（例: 一部のブラウザが Required の指定を無視する等）。導入前にテスト環境で対象ブラウザ・デバイスでの挙動を検証してください。
有効化すると、iCloud キーチェーン、Google パスワードマネージャー、Keeper 等のサードパーティプロバイダーを含む、同期パスキーの新規登録が一括でブロックされます。既存登録を即時に無効化する機能ではありません。設計判断のセクション 5-3 で検討した方針に基づいて設定してください。本オプションは2026年2月現在、早期アクセスでの提供となりますが、設定は Admin Console の [設定] > [機能] からの有効化・無効化となります（下図）。
特定の同期プロバイダーのみ許可したい場合（例: Keeper は許可し、他の同期プロバイダーはブロック）は、この設定ではなく Authenticator グループによる AAGUID ベースの制御を使用します。詳しくはセクション 5-2「Okta における制御方法」、7-3「利用可能なパスキー基盤の制限」を参照してください。
本設定にはいくつかの制約事項があります。
組織のセキュリティポリシーに応じて、利用可能な FIDO2 (WebAuthn) Authenticator（パスキー基盤）を特定のデバイス・メーカーに限定できます。これは AAGUID (Authenticator Attestation Global Unique Identifier) と Authenticator グループを組み合わせて実現します。
Authenticator グループを作成し、Authenticator 登録ポリシーで指定することで、特定の Authenticator のみ登録・利用を許可する制御が可能になります。例えば以下のような運用を実現できます。
セキュリティキーの制限だけでなく、パスキー基盤（プラットフォーム Authenticator やサードパーティプロバイダー）の制限にも活用できる点がポイントです。
例として「Keeper と YubiKey 5 シリーズのみ許可し、それ以外はブロックする」場合の流れを示します。
これにより、FIDO MDS AAGUID リストに掲載されていないプラットフォーム Authenticator やサードパーティプロバイダーも含めて、組織が承認した Authenticator だけにパスキー利用を限定できます。
ヒント: プラットフォーム Authenticator やサードパーティプロバイダーの AAGUID は、コミュニティが管理している Passkey Authenticator AAGUIDs Explorer で確認できます。
本サイトでは iCloud キーチェーン (Apple Passwords)、Google パスワードマネージャー、Windows Hello、Keeper、1Password など主要なパスキー基盤の AAGUID の一覧を提供しています。セキュリティキーの AAGUID については、Okta の FIDO MDS AAGUID リストまたは FIDO Alliance Metadata Service (MDS) を参照してください。
注意: Authenticator グループを使用している場合、FIDO U2F (Universal 2nd Factor) によるセキュリティキーの登録はサポートされません。
FIDO MDS AAGUID リストおよびカスタム AAGUID から、許可する Authenticator のグループを作成します。
設定手順:
追加した Authenticator グループは以下のように一覧に表示されます（下図は2つの Authenticator グループを追加した場合の例）。
作成した Authenticator グループは、Authenticator 登録ポリシーで指定します（セクション 7-4 で後述）。
FIDO MDS AAGUID リストに掲載されていない Authenticator（Windows Hello 等のプラットフォーム Authenticator、Keeper 等のサードパーティプロバイダーなどのパスキー基盤）を Authenticator グループに追加するには、カスタム AAGUID を登録します。
設定手順:
追加したカスタム AAGUID は以下のように一覧に表示されます（下図は3エントリを追加した場合の例）。
※カスタムエントリは FIDO MDS のエントリと AAGUID が重複した場合、カスタム側が優先されます。セキュリティキーの取得や環境へのデプロイを行う前に、Okta で利用可能な Authenticator を AAGUID リストで確認しておくことを推奨します。
Authenticator を追加しただけでは、ユーザーはまだパスキーを登録できません。Authenticator 登録ポリシーにパスキーを追加する必要があります。
| 設定 | 挙動 |
|---|---|
| 必須（Required） | ユーザーに登録を強制します。次回サインイン時に登録プロンプトが表示されます |
| 任意（Optional） | ユーザーが任意で登録できます。強制はしません |
| 無効（Disabled） | ユーザーはパスキーを登録できません |
段階的にロールアウトする場合は、例えば、まず特定のグループ（IT 部門など）のみに必須を適用して試験運用し、その後、全社グループに任意で展開、最終的に 必須に切り替えるのが安全です。
アプリケーションへのサインイン時にパスキーを利用できるようにするため、認証ポリシーを設定します。
| 設定項目 | 設定値 | 説明 |
|---|---|---|
| 認証方式 | 任意の2要素タイプ | 2要素認証を要求します |
| 所有要素の制約 |
・フィッシング耐性 |
・FIDO2 (WebAuthn) / Okta FastPass が条件を満たします ・ユーザーインタラクションを必須にするとパスキーのみで任意の2要素タイプの条件を満たすことができます（詳細はセクション10 Q3 を参照してください） |
フィッシング耐性を要求すると、FIDO2 (WebAuthn) または Okta FastPass でしかサインインできなくなります。FIDO2 (WebAuthn) にはパスキーだけでなくセキュリティキーによる認証も含まれます。パスキー未登録のユーザーがロックアウトされないよう、登録ポリシーと合わせて検討してください。
ここでは、エンドユーザーがパスキーを登録・認証する際の実際の操作フローを説明します。
| 項目 | バージョン等 |
|---|---|
| OS | macOS Tahoe 26.3 |
| ブラウザ | Google Chrome 145.0.7632.76 |
| クロスデバイス認証用のスマートフォン | iPhone 17 Pro / iOS 26.3 |
ユーザーがパスキーを登録する方法は2つあります。
Authenticator 登録ポリシーで必須または任意に設定している場合、設定後の初回ユーザーのサインイン時に登録プロンプトが表示されます。
※ ユーザーあたり最大10個 の FIDO2 Authenticator （パスキーおよびセキュリティキー）を登録できます。リカバリに備えて、複数デバイス・複数ブラウザでの事前登録をユーザーに推奨してください。
登録が完了すると、ユーザーは以下の方法でサインインできます。
設定でパスキー自動入力オプションを有効化している場合（セクション 7-2 参照）、ユーザー名の入力を省略できます。
この方法を使えば、PC に生体認証デバイスが内蔵されていない場合でも、手元のスマートフォンでパスキー認証を完了できます。
利用可能なパスキー基盤の制限を実施している場合（設定方法はセクション 7-2、7-3 を参照）は、パスキーの登録時およびパスキーでの認証時に以下のエラーが表示され、登録・認証がブロックされます。
実際にパスキーを運用してみると、公式ドキュメントだけでは分かりにくい落とし穴がいくつかあります。ここでは、管理者が事前に把握しておくべきポイントをまとめました。
ブラウザや OS によってパスキーの挙動が異なる場合があります。事前に把握しておくと、円滑にトラブルシューティングができます。
| OS | ブラウザ | 主な挙動 | 運用上の注意点 |
|---|---|---|---|
| macOS | Chrome | パスキー選択時に内蔵 Authenticator (Touch ID 等) が先に提示される場合あり。ブラウザデータ消去で再登録が必要になる場合あり | セキュリティキーを使わせたい場合は「別の方法を選択」をユーザーに案内 |
| macOS | Safari / Firefox | 生体認証パスキー利用時に iCloud サインイン状態が前提になる場合あり | 事前チェック項目に iCloud サインイン状態を含める |
| Windows | Edge / Chrome | Windows Hello で顔認証または PIN を設定すると他の認証方法も有効になる場合あり。「推奨（Preferred）」でも CTAP2 経由で PIN 設定を求められる場合あり | 「生体認証が推奨 (Preferred) でも PIN が出る」ケースをユーザーに案内 |
| iOS | Safari / Chrome / Edge | いずれも WebKit ベースで、端末側のパスキー基盤（iCloud キーチェーン等）を利用して認証 | 同期パスキーをブロックしている場合、iOS 16 では FIDO2 (WebAuthn) が利用できない制約があるため、OS バージョンを事前確認。必要に応じて FastPass や NFC / USB-C セキュリティキーを併用 |
| Android | Chrome | Google パスワードマネージャーとの連携でパスキーが自動同期。CDA の Authenticator として利用可能 | 同期パスキーをブロックしている場合、Android からの登録ができない場合あり |
| ChromeOS | Chrome | パスキーの作成・利用が可能だが、プラットフォーム Authenticator※ の対応は端末に依存 | Okta FastPass が非対応のため、FIDO2 (WebAuthn)（パスキー / セキュリティキー）が実質的なフィッシング耐性オプション |
※ プラットフォーム Authenticator は、端末内蔵の Authenticator（Windows Hello、Touch ID、Face ID など）を指します。詳しくは下記公式ドキュメントを参照してください。
可能です。 Okta の FIDO2 (WebAuthn) Authenticator は、パスキーとセキュリティキーの両方をカバーしています。ユーザーは最大 10 個まで登録でき、パスキーとセキュリティキーを混在させることも可能です。
同期パスキーの場合: 別のデバイスで同じクラウドアカウント（iCloud、Google アカウント、Keeper アカウント等）にサインインすれば、パスキーは自動的に同期されます。
デバイスバウンドパスキーの場合: 紛失したデバイスに紐づくパスキーは使用不能になります。以下の順で対処します。
重要: リカバリの事前設計については、本記事のセクション 5-4 を参照してください。FIDO2 の登録は単一のブラウザ・デバイスだけに依存するとロックアウトのリスクがあるため、複数ブラウザ・複数デバイスでの事前登録を推奨します。
条件付きで可能です。 Okta OIE ではパスワードレスサインインがサポートされています。
実現するには以下の条件をすべて満たす必要があります。
これにより、パスキーが 所有要素 (Possession) と 生体要素 (Biometric) を同時に提供し、パスキー単独で2要素認証の要件を満たせます。ただし、全ユーザーのパスキー登録が完了し、リカバリフローが整備されていることが前提となるため、段階的に移行することを推奨します。
注意: パスキーは、所持要素に加えてユーザー検証 (PIN または生体認証) を伴う強力な認証手段です。一般的な FIDO2 / WebAuthn 規格では、PIN と生体認証はともにユーザー検証として同等に扱われます。しかし、Okta のパスワードレス設定においては、所有要素と生体認証要素の両方を満たすことが求められます。
一般的な移行アプローチは以下の通りです。
具体的な移行の流れの例を下図にまとめました。
組織のセキュリティ要件次第となります。
より高いセキュリティが求められる場合に有効な設定ですが、まずは検証環境で動作を確認してから、本番環境へ展開することをお勧めします。
Okta でのパスキー導入は、Authenticator の追加設定自体はシンプルですが、導入前の設計判断、ポリシー設計、運用時の例外対応まで含めて整理しておくと、展開後の手戻りを減らしやすくなります。
特に押さえておきたいポイントは次の4点です。
まずは小規模なグループでのパイロット運用から開始し、段階的に全社展開を進めていくアプローチが最も確実です。
本記事が、皆様の Okta 運用におけるパスキー導入検討の一助となれば幸いです。
Okta の導入に関心をお持ちの方、本記事では紹介できていない、詳細なライセンス体系や価格などをお知りになりたい方は、ぜひ弊社窓口までお問い合わせください。