パスキー日本 2026：規制・導入状況と実装課題

2025年、日本はセキュリティ課題の深刻化を受けて、パスキー（Passkeys）の導入を一気に加速させました。金融業界で不正アクセス被害が増加したことを受け、規制当局は**「IDとパスワードのみの認証、さらにはメールやSMSによるワンタイムパスワード（OTP）だけでは不十分である」と強調し、リスクの高い金融取引においてはパスキーのような強固な認証方法を優先すべき**だという方針を打ち出しました。

その結果、年末までに50以上のパスキープロバイダーがサービスを開始（または計画）し、FIDOアライアンスのJapan Working Groupには64の組織が参加しました。業界には「数年」ではなく「数ヶ月」での対応が求められ、まさに待ったなしの状況でした。

しかし、日本の急速な展開は、米国や欧州の導入事例ではあまり見られない形でFIDOエコシステムの限界を試すことにもなりました。企業におけるWindows/Edgeの高いシェア、多種多様なAndroidメーカー（OEM）の存在、そして厳格な企業ネットワークポリシー。これらが組み合わさることで、特にAndroidパスキーのQRコード連携、iPhoneとのクロスデバイスフロー、マルチデバイス登録などの領域で、グローバル市場向けに開発しているプロダクトチームが見落としがちな「エッジケース」が浮き彫りになったのです。

この記事では、以下のトピックについて解説します。

1. 導入企業の実状：楽天証券、野村證券、SBI証券、マネックス証券などの現状
2. きっかけ：規制強化と不正被害のタイムライン
3. なぜAPACは特殊なのか：AndroidとiPhoneの断片化問題
4. 何がうまくいかないのか：現場で頻発する実装の壁
5. どう対処すべきか：戦略的な推奨事項

日本の金融機関は、新たな規制要件を満たすために素早い動きを見せています。以下は、2025年後半時点での状況をまとめたスナップショットです。

ステータス： 提供中（2025年11月29日よりパスキー認証を必須化）

野村證券は全ユーザーに対してパスキー認証を必須化しました。主な特徴は以下の通りです。

• 「NOMURAアプリ」経由での登録
• より安全な取引のために、フィッシング耐性のある「パスワードレス」な仕組みとして位置づけ
• 既知のAndroid問題：特定のAndroid端末やOSの組み合わせにおいて、「M0902」エラーや「操作が中断されました」というエラーが報告されています（トラブルシューティング、サポート情報）。

野村證券サポート

ステータス： 提供中（2025年10月26日導入）

楽天証券は、クロスデバイス対応を強化したFIDO2パスキー認証を展開しました。

• すべての取引チャネルでFIDO2パスキー認証を利用可能
• スマートフォンのパスキーを使ってPCにログインできるクロスデバイス（QRコード）フローに対応
• パスキーへの移行を強く推奨

楽天証券 お知らせ

ステータス： 提供中/計画中（FIDOは2021年から、FIDO2パスキーは2025年秋までに）

SBI証券はFIDOの早期導入企業のひとつであり、現在は完全なパスキー対応へと移行中です。

• 「パスワード + SMS OTP」からの置き換え
• まずはWebから導入し、続いてネイティブアプリへ展開
• 過去の不正被害に対する補償請求への対応策としても導入を推進

Impress Watch記事

ステータス： 提供中（2025年10月31日導入）

マネックス証券は幅広いプラットフォームサポートと明確なセキュリティメッセージを打ち出してローンチしました。

• 広範なOSサポート：Windows 11+、macOS 13+、Android 11+、iOS 16+
• Webとアプリで統一された体験
• 「フィッシング耐性」を明確にアピール

マネックス証券 お知らせ

ステータス： 進行中（2025年 秋〜冬）

PayPay証券は、強く推奨されるオプション機能としてパスキーを展開しています。

• 「強く推奨」される任意機能としての位置づけ
• ログインや出金時のメール通知を補助的なシグナルとして追加
• 複数の取引アプリおよびPCサイトをカバー

Impress Watch記事

ステータス： 提供中（2025年）

リクルートIDはマルチデバイス対応のパスキーを実装しました。

• 複数端末での登録をサポート
• 共有デバイスや公共のデバイスでの登録を行わないよう強く警告

リクルート お知らせ

ステータス： 停止中（2025年中頃、新規生体認証登録を一時停止）

アコムは登録プロセスのセキュリティを見直し・強化するために新規の生体認証登録を一時停止しました。これは重要な教訓を含んでいます。いくらフィッシング耐性のある認証器であっても、最初の登録時に厳格な確認を行わなければ、不正アクセスを防ぐことはできません。

アコム FAQ

ステータス： 計画中（2026年2月9日よりパスキー必須化）

みずほ証券は、重要な口座操作すべてにおいてパスキーを必須化する予定です。

• 対象：取引、入出金、「ネット倶楽部」および「株アプリ」での口座情報の変更
• 対応環境：Windows 11 (Edge/Firefox/Chrome)、macOS 14+、iOS 17+、Android 10+
• Windows Hello、iCloudキーチェーン、またはGoogleパスワードマネージャーを使用

みずほ証券 FAQ

日本におけるパスキーの急拡大は、単なるUX改善のトレンドではありませんでした。フィッシングによるアカウント乗っ取り（ATO）が深刻化し、規制当局が直接介入せざるを得なくなったことへの「防御的な反応」だったのです。

2025年1月の対話資料において、金融庁（FSA）はフィッシング被害を主要な不正チャネルとして挙げ、DMARCや迅速なテイクダウンと並んで**「パスキー利用の促進」**を対策として明記しました。また、2024年12月24日には警察庁との連名で、より強力なフィッシング対策を要請する注意喚起を行っています。

2025年半ばまでに、金融庁は「インターネット証券取引における不正アクセスおよび不正取引」を強調し、現代の脅威に対してID・パスワードのみの認証では不十分であると明確に述べました。

2025年7月15日、日本証券業協会（JSDA）はインターネット取引における不正アクセス防止ガイドラインの改正案を公表しました。この案では、ログイン、出金、銀行口座変更のフローにおいて、フィッシング耐性のある多要素認証（MFA）の実装と必須化（デフォルトオン）を求めており、その具体例としてパスキーが明記されました。また、検知・通知およびロックアウト制御の基準も引き上げられました。（JSDA ガイドライン改正案 PDF、報道記事）

証券業界でのフィッシング危機とそれに続く規制当局のプッシュの直接的な結果として、2025年12月までにFIDOアライアンス Japan Working Groupの参加組織は64に達し、日本国内で50以上のパスキープロバイダーが稼働または計画中となっています。

アコムによる新規生体認証登録の一時停止（2025年中頃）は、有益な教訓です。フィッシング耐性のある認証器であっても、不正な紐付けを防ぐためには、最初の登録時に強力な本人確認が必要だということです。（アコム FAQ）

日本（および広義のAPAC市場）にパスキーを導入する場合、米国や欧州でのテスト環境とは異なる、より「多様で複雑な」デバイス・ネットワーク環境で運用することになります。

• 日本のトラフィックは「モバイルオンリー」ではありません。デスクトップの比重が依然として高いのが特徴です。
• 企業のWindows利用率が高く、Edgeのシェアも多くの市場より顕著に高くなっています。
• 「デバイスの現実」を知るには、StatCounterのモバイルベンダーや画面解像度の分布も参考になります。
• Androidエコシステムは多様です（OEMやキャリアによるカスタマイズ）。パスキーの挙動は、OS、ブラウザ、そしてプラットフォームの認証プロバイダー層（Google Play開発者サービスや認証情報マネージャーなど）の相互作用に依存します。その結果、「端末Aでは動くが、端末Bでは失敗する」といったデバッグ困難なエッジケースが多発します。
• OEM固有の導入ブロッカー： 条件付き作成（パスキーへの自動アップグレード）のような高度な登録機能は、Google Pixelデバイスと比較して、「OEM Android」ハードウェア（Pixel以外のデバイス）での成功率が著しく低い傾向にあります。例えば、多くのSamsungデバイスはSamsung Passを優先的な認証マネージャーとしてデフォルト設定しており、これがGoogleパスワードマネージャーとの連携を前提としたバックグラウンドでのパスキー作成を阻害することがあります。
• 認証情報マネージャーのシステムバグ： Android 14における重大なハードルとして、文書化されたシステムバグがあります。これにより、認証情報マネージャーAPIがパスキー選択UIを正しく表示できなかったり、「認証情報が見つかりません」というエラーを返したりします。この問題はOEMハードウェアで不均衡に発生しており、重要な金融アプリの展開時に予期せぬ摩擦を生んでいます。
• OEM Androidの課題： 最近の金融アプリの展開に関する独自分析により、特定のAndroid 14デバイス（Samsung Galaxy A、Sony Xperia、Sharp AQUOSの人気モデルを含む）における認証の課題が特定されています。Google独自の実装は最新のFIDO標準に準拠している傾向があるため、これらの問題はPixel以外のハードウェアで顕著です。詳細なトラブルシューティングについては、現地のサポートリソースも参照してください。
• これは仮定の話ではありません。2024年のNDSSの論文で公式のOEMセキュリティアップデート・データセットを分析した結果、大手Android OEMが一度にどれほど多くの地域/国/キャリアのバリエーションをサポートしているかが示されています（例：Samsungは97カ国、109キャリアにまたがる402デバイスの約1,400のユニークモデルをサポート。Xiaomiは10地域で223デバイス）。この論文では、こうした作業負荷が一部のセキュリティアップデートの遅延（あるいは失敗）を招き、パッチがユーザーに届くのが遅れたり不均一になったりすることも指摘されています。

日本の組織が仕様検討から本番運用へと移行する中で、いくつかの「失敗パターン」が繰り返し発生しています。これらの実例は、標準的なテスト環境とAPACでの展開現実とのギャップを物語っています。

サービスプロバイダーが規制ガイドラインに間に合わせるためにパスキー導入を急ぎ、デバイスレベルのテレメトリ（利用状況データ）を持たないまま、全ユーザーに一斉導入してしまうケースです。

• 失敗の内容： 開発チームの手元のテスト端末では「成功」していても、断片化されたOEM製ハードウェアではその3倍もの失敗率が発生していることに気づけません。ユーザーは混乱し（非対応端末、プラットフォームアカウントの設定不備など）、離脱してしまいますが、銀行側には「なぜ」「どこで」つまずいたのかを説明するデータがありません。

ユーザーが企業ネットワーク内や自宅の書斎から、クロスデバイスパスキー認証（PC ↔ スマホ）を試みるケースです。

• 失敗の内容： 「ハッピーパス（理想的な動線）」ではBluetoothやハイブリッドフローが完璧に動作することを前提としています。しかし現実には、企業のプロキシがFIDOハイブリッドフローに必要な通信をブロックすることが頻繁にあります。多様なアクセス環境を想定した計画がない場合、シームレスなはずのログインが、永続的な接続エラーに変わってしまいます。

以前は動作していたフローがOSアップデート後に失敗するようになったり、特定のメーカー製端末（Samsung、Sony、Sharpなど）でのみ失敗したりするケースです。

• 失敗の内容： 文書化されているAndroid 14のバグや、OEM固有のデフォルト設定（Samsung Passなど）が標準的なフローを阻害します。パスキープロバイダー層の挙動がバージョンによって一貫しないため、QRコードの引き継ぎ失敗や「認証情報が見つかりません」といったエラーが発生し、デバイス固有の監視データなしには原因特定が不可能です。

サービス側がパスワードによるフォールバック（予備手段）を早く無効にしすぎたり、初期登録時の本人確認が不十分だったりするケースです。

• 失敗の内容： 初期登録が安全でない場合（アコムの事例のように）、盗んだパスワードを持つ攻撃者が自分のパスキーを登録してしまう恐れがあります。逆に、2025年の義務化に合わせて銀行が「完全パスワードレス」に移行した場合、登録時のトラブルやデバイスの不具合が発生すると、従来の安全策（パスワード）が使えないため、ユーザーは完全にアカウントから締め出されてしまいます。

上記のリスクを軽減するために、プロダクトチームとセキュリティチームは予防的なアーキテクチャを採用する必要があります。最も重要な推奨事項を以下にまとめました。

1. 認証の可観測性（Observability）と段階的ロールアウトへの投資 サポートへの問い合わせが殺到する前に「3倍の失敗率」のギャップを検知できるよう、デバイス、OS、ブラウザごとにパスキーのプロンプト表示から完了までの率を追跡してください。

   • Webの場合：OSバージョンやブラウザの種類ごとに段階的にロールアウトする。
   • ネイティブの場合：特定のデバイスモデル（例：Pixelを最初に、次に各OEMメーカー）ごとに段階的に展開し、リグレッションを早期に発見する。
   • モニタリング：保存場所（システム vs サードパーティ）を継続的に監視し、締め出しリスクを把握する。

2. 「登録」をセキュリティの攻撃対象領域として扱う フィッシング耐性のある認証も、最初の紐付けが弱ければ意味がありません。攻撃者がパスワードレスへの移行を「乗っ取る」のを防ぐため、パスキー登録の前にはステップアップ認証（eKYCや既存の強力な要素による確認）を必須にしてください。

3. 完全なパスワードレスへの準備 初期ログインにおけるパスワードの完全廃止に向けた規制圧力は加速すると予想してください。つまり、セクション5で挙げた技術的課題を解決することは、コンプライアンス上の必須事項となります。パスワードという逃げ道がなくなれば、デバイスレベルの失敗は即座に「完全な締め出し」を意味するからです。

4. APAC重視のデバイステスト構成を組む 日本ではSamsung、Sony、Sharpのモデルが大きなシェアを占めています。テスト対象が限定的であれば、バグを含んだままリリースすることになります。日本市場に多いOEMを含め、推奨事項1で得られたデータを使ってサポート対象デバイスリストをリアルタイムで改善してください。

5. マルチデバイス・マルチアクセス環境を前提に設計する BluetoothによるCDA（Client Device Assertion）や企業のプロキシは失敗すると想定してください。明確なネットワーク要件を提示し、マルチデバイス登録などの堅牢なフォールバック手段を用意することで、環境やアクセスポイントに関わらずユーザーが認証できるようにします。

6. 高保証の補完手段としてハードウェアセキュリティキーを評価する 制限の厳しい企業環境にいるユーザーや、最高レベルの保証を必要とするユーザーには、同期パスキーの強力な代替手段としてハードウェアセキュリティキー（YubiKeyなど）が有効です。これらは物理的な信頼の起点（Root of Trust）を提供し、モバイルやレガシーなデスクトップを含むほぼすべてのデバイスで一貫して動作します。プラットフォーム固有のクラウド同期やBluetooth接続にも依存しません。堅牢なアーキテクチャであれば、これらハードウェアベースの認証器とプラットフォームパスキーを共存させ、ユーザーがアクセス状況に合わせて最適な「鍵」を選択できるようにすべきです。

7. サポートのボトルネックを防ぐために復旧を自動化する パスワードレスモデルへの移行を持続可能にするには、弱い認証方法を復活させない形での合理的な復旧プロセスが必要です。日本の金融のような高セキュリティ分野では、SMSやメールによるリセットではなく、自撮りによる本人確認や、信頼できるハードウェアを使ったクロスデバイスフォールバックなど、「スマートMFA」による復旧を意味します。自動化された復旧プランがなければ、パスワードリセットの問い合わせが減っても、複雑な「パスキー紛失」のサポート電話が急増し、コスト削減効果が相殺されてしまいます。

結論： 日本での経験が示すのは、「仕様への準拠」と「実際のユーザー環境での動作」のギャップが、多くのチームが予想する以上にAPACでは大きいということです。勝者となるのは、デバイスの断片化と登録時のセキュリティを最優先のエンジニアリング課題として捉え、専用のオーケストレーション層を使ってそのギャップを埋めるチームでしょう。

日本の金融機関にとって、パスキーへの移行はもはや「UXの実験」ではありません。それは詐欺被害率や運用コストに直結する、待ったなしのコンプライアンス要件です。しかし、最近の導入事例が示すように、「パスキー機能をリリースすること」は始まりに過ぎません。真の課題は、日本の断片化されたデバイスエコシステムの現実を管理することにあります。

Corbadoは、既存のIDプロバイダー（IDP）やWebAuthnサーバーの上に配置されるパスキーの可観測性と導入支援レイヤーを提供します。私たちは、「仕様準拠」と「実社会での成功」の間のギャップを埋めるお手伝いをします。

多くの銀行は高度な不正検知テレメトリを持っていますが、パスキーログインの「フロントエンド中心」のジャーニーについては可視性がゼロです。

• 課題：ログに「ログイン失敗」と出ても、それがAndroid 14のバグなのか、Samsung Passの競合なのか、UIがわかりにくくてユーザーがキャンセルしたのかがわかりません。
• Corbadoのソリューション：認証に特化した可観測性を提供し、特定のデバイスモデル、OSバージョン、ブラウザごとのプロンプト完了率を追跡します。ハードウェアセキュリティキーと同期パスキーの利用状況もモニタリングできるため、どの要素が特定のユーザーセグメントで最も高い成功率を出しているかを正確に把握できます。

必須化の展開には、ユーザーのハードウェアや環境にリアルタイムで適応する戦略が必要です。

• 課題：クラウド同期が無効化されている企業環境や、認証情報マネージャーが破損しているOEMデバイスのユーザーに対して、単一の認証パス（同期パスキーなど）を強制すると失敗します。
• Corbadoのソリューション：当社の導入インテリジェンスにより、プラットフォームパスキーとハードウェアセキュリティキーの両方をシームレスに統合する柔軟なポリシーを定義できます。問題のあるデバイスや制限されたネットワークのユーザーに対して、YubiKeyなどをプレミアムまたは高保証のフォールバックとして提示することで、サポートの負担を増やさずに100%の到達率を確保できます。

パスワードレスへの移行はアカウント復旧の重要性を高めます。デバイス紛失時のレガシーな逃げ道がなくなるからです。

• 課題：復旧フローのハードルが高すぎると、ユーザーは高コストな店舗や電話窓口に殺到します。逆にハードルを下げれば、安全でないSMS/メールリセットを復活させることになります。
• Corbadoのソリューション：ユーザーの行動に基づいて、外部の復旧ソリューションやプロセスを統合します。ハードウェアセキュリティキーや、システムで定義されたその他の高保証な復旧要素を明示的に要求することで、ユーザーがメイン端末を紛失しても、日本の規制基準を満たす確認方法で、人手を介さずにアクセスを回復できるようにします。

パスワードというフォールバックを削除することは2025年の規制ロードマップのゴールですが、データなしにそれを行うのはユーザーアクセスにとって致命的なリスクです。

• 課題：特定のSonyやSharpのモデルでリグレッション（不具合）が発生した場合、強制的なロールアウトを実施中だと、即座に数千人のアカウントがロックアウトされる可能性があります。
• Corbadoのソリューション：当社のプラットフォームでは、さまざまな認証タイプをユーザーベース全体でパイロット運用し、技術環境ごとに段階的にロールアウトできます。特定のデバイスとOSの組み合わせで失敗が急増した場合、アプリストアのアップデートを待たずに、デバイス単位のキルスイッチで即座にその組み合わせを無効化できます。

大手銀行にとって、規制やセキュリティの理由からWebAuthnサーバーとユーザーデータを自社で管理することは譲れない条件であることを理解しています。

• Corbadoのアプローチ：私たちはIDPではありません。 既存のスタック、ユーザーデータベース、セキュリティポリシーはそのまま維持してください。Corbadoはその上に「インテリジェンスと可視性のレイヤー」を追加し、既存のSIEMや不正検知ツールで期待されるのと同様の、パスキーやセキュリティキーのジャーニーに関する詳細な可視性を提供します。

日本におけるフィッシング耐性のあるパスワードレスな未来への移行は避けられませんが、それがサポート部門の悪夢になる必要はありません。詳細な可視性とインテリジェントな導入戦略を組み合わせることで、金融庁の必須要件を満たしつつ、デバイスに関係なくすべてのユーザーにシームレスな体験を提供できます。既存のソリューションへのSDK統合やロールアウト計画について、ぜひお問い合わせください。

以下の質問は、検索トレンド、サポートチケットの傾向、コミュニティでの議論から導き出された、パスキーに関して日本のユーザーから最も頻繁に寄せられる質問です。ユーザーが移行期に直面する本当の意図や混乱に対処するため、自然な質問形式で回答します。

主な原因として、デバイスやブラウザの不一致（作成時と異なる環境でパスキーが表示されない）、アプリ内ブラウザ（WebView）の制限、あるいは企業のプロキシがクロスデバイス認証に必要な通信をブロックしていることなどが考えられます。登録時と同じブラウザやプロファイルを使用するか、アプリ内ブラウザではなくシステムのフルブラウザでサイトを開いてみてください。

この一般的なエラーは、通常、ブラウザとプラットフォーム認証器（端末の認証機能）との間の通信失敗を示しています。OSとブラウザが最新であることを確認してください（例：最新のiOS、またはPlay開発者サービスが更新されたAndroidなど）。

アカウントにアクセスできない場合は、以下を確認してください。(1) パスキーを作成したのと同じデバイスまたはクラウドエコシステムを使用しているか、(2) デバイスに画面ロック（生体認証やPIN）が正しく設定されているか、(3) サービス側でセキュリティ設定がリセットされていないか。完全にロックアウトされた場合は、サービスのアカウント復旧フローを使用するか、サポートに連絡してください。

一般的なパスキーエラーは、古いブラウザやサポートされていないOSの使用に起因することが多いです。最新のOSバージョンでモダンブラウザ（Chrome、Edge、Safari）を使用しているか確認してください。また、デバイスの時計が合っているか、インコグニトモード（プライベートモード）でないかも確認してください（パスキーの保存や呼び出しに干渉することがあります）。

パスキーのプロンプトが起動しない場合：Bluetoothが有効になっているか確認してください（クロスデバイス/QRコードフローでは必須です）。また、サイトがHTTPSを使用しているか、ブラウザの拡張機能（広告ブロッカーやパスワードマネージャーなど）がWebAuthnの呼び出しと競合していないかも確認してください。ブラウザやデバイスの再起動で一時的な不具合が解消することもよくあります。

システムのパスキーダイアログが表示されない場合、WebAuthnをサポートしていないWebView（アプリ内ブラウザ）にいる、プラットフォームの認証情報マネージャーが無効になっている、あるいはパスキーが別のプロファイルに存在している可能性があります。Androidでは、Google Play開発者サービスが実行されており、パスキーUIで正しいGoogleアカウントが選択されているか確認してください。

「くるくる（読み込み中）」の状態は、多くの場合、ブラウザがBluetooth経由で認証デバイスとの接続を待機している（クロスデバイスフローの場合）か、ユーザーの操作を待っている状態です。ローカルパスキーを使用している場合、生体認証のプロンプトが別のウィンドウの後ろに隠れていたり、別のプロンプトが開いたままになっていたりしないか確認してください。

このエラーは、ユーザーが明示的にキャンセルした場合、タイムアウトした場合、またはフォーカスが外れた場合に表示されます。すぐに認証をやり直してください。生体認証のプロンプトは素早く完了させ、プロセス中にアプリを切り替えたり画面をスリープさせたりしないようにしてください。なお、2025年11月の必須化以降、Androidを利用する野村證券ユーザーからこのエラーが頻繁に報告されており、デバイスやOSの互換性問題に関連しているケースがあります（詳細な分析）。

同期パスキー（iCloudキーチェーン、Googleパスワードマネージャー）は、新しい端末で同じクラウドアカウントにサインインすると自動的に引き継がれます。デバイス固定のパスキー（YubiKeyや同期されないプラットフォーム認証情報）は引き継がれません。古い端末を初期化する前に、新しい端末で新しいパスキーを登録する必要があります。

適切な削除は2段階のプロセスです。(1) サービス側のセキュリティ設定ページからパスキーを削除して要求されないようにし、(2) デバイス側のパスキーマネージャー（iCloudキーチェーン、Googleパスワードマネージャーなど）から認証情報を削除してローカルストレージを整理します。

パスキーにおいて「転送」という表現は正確ではありません。通常はクラウド（Apple/Google）経由で「同期」するか、新しく「登録」します。エコシステムをまたぐ場合（例：iPhone → Android）、既存のパスキーは移行できません。新しいスマホで（パスワードやクロスデバイス認証を使って）ログインし、そこで全く新しいパスキーを作成する必要があります。

設定は一般的に以下の流れで行います。(1) サービスにログインする、(2) アカウント/セキュリティ設定に進む、(3) 「パスキーを作成」を選択する、(4) システムプロンプトが表示されたら生体認証/PIN確認を行う。パスキーはデバイスの画面ロック機能を前提としているため、FaceID、指紋認証、またはPINが有効になっていることを確認してください。

同期パスキーの場合、1つの登録でそのエコシステム内のすべてのデバイス（例：すべてのAppleデバイス）をカバーできます。異なるエコシステム間（例：iPadとWindows PC）で利用する場合、ログインのたびにQRコードを使わなくて済むよう、それぞれのプラットフォームでパスキーを登録することをお勧めします。ほとんどのサービスでは、1つのアカウントに複数のパスキーを登録できます。

唯一のパスキーが入った端末を紛失した場合：利用可能であれば代替手段（パスワード、バックアップコード、メールのマジックリンク）を使用してください。サービスが「パスキー専用」の場合、本人確認やアカウント復旧プロセスを経る必要があります。同期パスキーを使用していれば、他のデバイスやクラウドアカウントに認証情報が残っているため、このリスクを軽減できます。

パスキーはユーザー個人のクラウドアカウントに厳密に紐付いているため、デジタル遺産としての継承は極めて困難です。紙に書いたパスワードとは異なり、家族がただパスキーを「使う」ことはできません。サービス側でも近親者によるアカウントアクセスの法的プロセスを整備し始めていますが、依然として複雑な課題となっています。

AndroidのパスキーはGoogleパスワードマネージャーとGoogle Play開発者サービスに依存しています。その体験はメーカー（Samsung、Sony、Sharpなど）によって異なる場合があります。クロスデバイス（QR）フローの場合、OEM製のカメラアプリがFIDO QRコードを認識しないときは、システム標準のスキャナーやGoogleレンズを使用してください。

iPhoneのパスキーはiCloudキーチェーンに統合されています。同じApple IDでサインインしているiOSおよびmacOSデバイス間で一貫して動作します。設定で「iCloudキーチェーン」と「パスワードとパスキーの自動入力」が有効になっていることを確認してください。

Windows 11はWindows Helloを通じてネイティブにパスキーを管理します。パスキーはローカルに保存（顔/指紋/PINで保護）するか、ブラウザプロファイル（例：ChromeのGoogleアカウント）経由で同期できます。企業のPCではITポリシーによりWindows Helloの利用が制限されている場合があり、その際はモバイル端末認証（QRコード）やセキュリティキーの使用が必要になります。

高齢者のユーザーにとって、「パスワードがない」という概念やQRコードスキャンの操作はハードルが高い場合があります。最新のAndroidを搭載した「らくらくスマートフォン」的な端末であれば技術的にはパスキーに対応しているかもしれませんが、UXの障壁は高いです。設定には家族のサポートが必要になることが多いでしょう。サービス側は、この層のために代替のログイン手段を厳格に維持すべきです。

パスキーは、パスワードの代わりとしてデバイス内に保存される安全なデジタルキーです。秘密の文字列を入力する代わりに、デバイスのロック解除（顔、指、PIN）を行って本人であることを証明します。Webサイト側には秘密鍵が渡らないため、情報漏洩やフィッシングに強いのが特徴です。

パスキーはパスワードよりも格段に安全です。フィッシング耐性があり（偽サイトでのログインを騙し取られない）、ユニーク（使い回しがない）だからです。ただし、安全性は初期登録に依存します。もし攻撃者があなたのパスワードを知っていれば、あなたが登録する前に攻撃者が自分のパスキーを登録してしまう可能性があります。

主なデメリットは以下の通りです。(1) デバイス依存：クラウドアカウントやデバイスへのアクセスを失うと締め出されるリスクがある、(2) 共有デバイスでの摩擦：パスキーは個人用であり、家族共有や公共のPCでは使いにくい、(3) アカウント連携の課題：家計簿アプリ（マネーフォワードなど）のようなレガシーな接続方法に依存するサービスは、銀行がAPIを提供せずにパスキー専用に移行すると接続できなくなる可能性がある、(4) 企業ネットワークによるブロック：クロスデバイス認証プロトコルが遮断されることがある。