パスワードを使わずに指紋や顔認証でログインできる「パスキー」は、フィッシングに強く使い勝手もよい認証方式として、GoogleやApple、主要なWebサービスで対応が広がっています。自社サービスのログインに取り入れられないか検討する開発・プロダクト部門も増えています。
一方で、便利さや安全性が語られる機会が多い分、導入を考えるうえでは弱点や注意点も押さえておきたいところです。パスキーにも、端末を失ったときの扱いや対応環境の差、フィッシング耐性の限界といった、知っておくべきデメリットがあります。
本記事では、パスキーの主なデメリットをまず一覧で示し、それぞれが実際にどこまで影響するのかを整理します。あわせて「フィッシングに強い」という評価の限界、個人利用と企業導入での効き方の違い、そして自社サービスに導入する際にこれらのデメリットを設計で補う方法まで解説します。
目次
パスキーのデメリット一覧（まず結論）
パスキーには便利さの裏に、導入前に押さえておきたい弱点があります。主なデメリットは次の5点です。いずれも後の章で「実際にどこまで効くのか」を掘り下げます。
- 端末の紛失・故障でログインできなくなることがある：パスキーはスマートフォンやPCなどの端末に保存されます。クラウドに同期する設定なら別の端末から使えますが、特定の端末にだけ保存する方式では、その端末を失うとそのパスキーは使えません。
- 対応しているサービス・環境がまだ限られる：主要なプラットフォームや大手サービスは対応を進めていますが、すべてのサイト・アプリが対応しているわけではありません。対応状況は時期によって変わります。
- 共用PC・共有アカウントでは使いにくい：パスキーは個人の端末やアカウントに紐づく資格情報のため、1台を複数人で使う環境や、1つのアカウントを共有する使い方には向きません。
- 別のOS・エコシステム間での移行にひと手間かかる：同期の範囲は同じプロバイダのアカウント内に閉じるため、Apple と Google を併用する場合などは、移行や使い分けに手間が生じます。
- 「フィッシングに強い」は万能ではなく、残る攻撃経路がある：パスキーは通常のフィッシングを構造的に防ぎますが、弱い代替手段への誘導や、ログイン後のセッション乗っ取りなど、別の経路のリスクは残ります。
このうち、端末紛失への備えやフォールバックの扱いは、後述するように設計や運用で補いやすいデメリットです。一方、対応環境の差やエコシステムをまたぐ移行の手間は、現時点では完全には解消できず、許容できるか見極めが必要なデメリットといえます。
以下では、まずデメリットが生じる理由となるパスキーの仕組みを簡単におさらいし、続いて各デメリットの実際の影響、安全性の限界、立場ごとの違い、そして企業が設計で補う方法の順に解説します。
パスキーの仕組みをおさらい（デメリットが生じる理由）
パスキーのデメリットは、その仕組みに根ざしています。ここでは弱点の理由を理解するために必要な範囲で、仕組みを簡単に確認します。
パスキーは、FIDO Alliance と W3C が策定した FIDO2 / WebAuthn（ウェブオースン）という標準にもとづく認証方式です。ログインするサイトごとに公開鍵と秘密鍵のペアを作り、公開鍵をサービス側のサーバーに、秘密鍵をスマートフォンやPCなどの端末内の安全な領域に保管します。
ログイン時は、指紋・顔認証やPINで端末内の秘密鍵を解錠し、サーバーから届いた要求に署名を返して本人を確認します。秘密鍵そのものや生体情報はサーバーへ送られません。
パスキーがフィッシングに強いとされるのは、この資格情報が特定のサイト（RP ID／オリジン）に結びつけられているためです。WebAuthn 仕様は、あるサービス（Relying Party＝資格情報を受け入れるサイト側）が発行した資格情報は「同じ RP ID から要求された操作でのみ使用できる」と定めています。偽ドメインでは署名が成立しないため、見た目をまねた偽サイトでは使えません。
出典・参考資料（2件）
重要なのは、パスキーには保存場所によって2つのタイプがある点です。FIDO Alliance は、クラウド経由で利用者の複数端末に同期されるものを「同期パスキー（synced passkeys）」、1つの端末から出ないものを「デバイスバウンドパスキー（device-bound passkeys）」と呼び分けています。
端末紛失時の復旧や、別のOSへの移行のしやすさは、このタイプの違いに左右されます。次章の各デメリットは、ここを起点に整理します。
各デメリットはどこまで効くのか
ここからは、一覧で挙げたデメリットのうち運用に直結する4点について、「実際にはどうなるのか」を掘り下げます。
端末の紛失・故障と復旧
「端末を失うとログインできなくなる」というデメリットは、パスキーのタイプによって影響が分かれます。同期パスキーであれば、同じプロバイダのアカウントにサインインした別の端末から引き続き利用でき、クラウド側にも保管されるため、1台を失っても復旧できます。一方、デバイスバウンドパスキーはその端末から出ないため、端末を失えばそのパスキーは使えなくなります。
同期の安全性は、同期先アカウントの保護に支えられています。Google も、同じ Google アカウントにサインインした Android 端末と Chrome ブラウザの間でパスキーを同期するため、1台を失っても別の端末から利用できます。Apple も iCloud キーチェーンで同様に同期します。
Apple は iCloud キーチェーンによるパスキーの同期について、「iCloud キーチェーンは、Apple が知り得ない強力な暗号鍵でエンドツーエンド暗号化されている」と説明しています。さらに「すべての関連端末を失った場合でも、パスキーが復旧できることが重要だ」として、iCloud アカウントと端末のパスコードなどを用いた復旧の仕組みを用意しています。
このように、復旧のカギは最終的に同期元アカウント（Apple ID／Google アカウントなど）の安全性に行き着きます。
出典・参考資料（1件）
したがって「端末を失うと詰む」かどうかは、同期を有効にしているか、復旧手段（同期元アカウントや予備の端末）を用意しているかで変わります。自社サービスにパスキーを導入する側は、利用者がこの備えを持てるよう、後述する復旧の動線を設計で用意することが要点になります。
対応サービス・環境の現状（いつ時点かを押さえる）
「対応サービスが限られる」というデメリットは、状況が動いている点に注意が必要です。Apple・Google・Microsoft の主要プラットフォームはいずれもOSやブラウザでパスキーに対応しており（各社公式ドキュメント、2026年時点）、大手サービスでも採用が進んでいます。
一方で、すべてのサイト・アプリが対応しているわけではありません。たとえば、アプリ内に埋め込まれたブラウザ（WebView）や古いブラウザでは、パスキーの登録・ログインがうまく動かないことがあります。
利用者が使いたいサービスやその利用環境が未対応なら、そこでは従来どおりパスワード等でログインすることになります。対応状況は動いているため、「対応サービスが少ない」という記述を見かけたら、それがいつ時点のものかを確認するとよいでしょう。
出典・参考資料（3件）
共用PC・共有アカウントでの使いにくさ
パスキーは、個人の端末やプロバイダアカウントに紐づく資格情報です。同期も「同じ Google アカウントの Android 端末と Chrome の間」「同じ Apple ID の端末間」というように、個人アカウントの範囲に閉じます。このため、1台のPCを複数人で使う環境や、1つのサービスアカウントを共有する使い方では、誰のログインなのかを切り分けにくく、運用に向きません。
これはパスキー自体の欠陥というより、個人単位で本人を確認する方式の性質によるものです。共用環境で使う場合は、利用者ごとに端末内のアカウントを分ける、あるいは共有用途には別の手段を併用するといった運用の工夫が要ります。
クロスプラットフォーム（Apple×Google併用）移行の手間
同期パスキーは、同じプロバイダのアカウント内でのみ同期されます。Google は「Google パスワードマネージャーのようなパスワードマネージャーにパスキーを保存でき、同じ Google アカウントにサインインした Android 端末と Chrome ブラウザの間で同期する」と説明しており、Apple は iCloud キーチェーンで同期します。
このため、Apple と Google を併用する利用者は、両方のエコシステムにそれぞれパスキーを用意する必要があり、一方から他方へそのまま持ち運ぶことは簡単ではありません。
別の端末での一時利用には、FIDO のクロスデバイス認証（手元のスマートフォンで別の端末のログインを承認する仕組み）が使えます。ただし Google の説明では「スマートフォンがPCの近くにあり、利用者がスマートフォン側でログインを承認する」ことが条件で、近接が前提です。恒常的な移行の手段ではありません。
この移行の手間を埋める標準として、FIDO Alliance は資格情報をエクスポート・インポートするための仕様（Credential Exchange Format／Protocol＝CXF／CXP）の整備を進めています。
ただし2026年時点で、CXF は 2025年8月14日付の Proposed Standard、CXP は 2024年10月3日付の Working Draft の段階です。規格の整備は進んでいるものの、Apple と Google の間でパスキーをすぐに移行できる状態が広く普及しているわけではない、という現状を踏まえて検討する必要があります。
出典・参考資料（3件）
「フィッシングに強い」はどこまで本当か（安全神話の線引き）
パスキーの利点として最もよく語られるのが「フィッシングに強い」という点です。これは事実ですが、「だから完全に安全」ではありません。ここでは、パスキーが構造的に防ぐ攻撃と、それでも残る経路を分けて整理します。
パスキーが構造的に防ぐ攻撃
パスキーは、通常のフィッシングと、パスワードの漏洩・使い回しに起因する攻撃を構造的に防ぎます。資格情報がサイト（オリジン）に束縛されているため偽サイトでは署名が成立せず、そもそも覚えるパスワードが存在しないため、漏れたパスワードを使い回される心配もありません。米国のサイバーセキュリティ・インフラセキュリティ庁（CISA）も、2022年10月のファクトシートで次のように位置づけています。
The only widely available phishing-resistant authentication is FIDO/WebAuthn authentication.（広く利用できるフィッシング耐性のある認証は FIDO/WebAuthn 認証だけである）
出典：Implementing Phishing-Resistant MFA（2022年10月）｜CISA
Microsoft も公式ドキュメントで、パスキーは「オリジンに束縛された公開鍵暗号を用いるため、資格情報が再生されたり悪意ある者と共有されたりしない」こと、そして認証器が登録先の正規サイトにのみ秘密を渡す仕組み（検証者なりすまし耐性）を備えることを説明しています。この範囲では、パスキーは従来の認証方式より明確に強い方式です。
よく心配される、偽サイトと本物のサイトの間に割って入ってやり取りを中継する遠隔のリアルタイムフィッシング（リレー型）も、パスキーでは成立させにくい攻撃です。資格情報がオリジンに束縛され、クロスデバイス認証もスマートフォンとPCの物理的な近接を前提とするため、遠隔でそのまま中継する攻撃は通りにくくなっています。
出典・参考資料（1件）
それでも残る攻撃経路
一方で、パスキーを導入しても守備範囲の外に残るリスクがあります。導入を検討する側は、この線引きを理解しておくことが過信による設計ミスを防ぎます。
弱い代替手段（フォールバック）への誘導です。多くのサービスは、パスキーが使えない場合に備えてパスワードやSMS・ワンタイムコードを残しています。Microsoft は、攻撃者が「ソーシャルエンジニアリング、資格情報の収集、あるいはパスキーやセキュリティキーのような強固な保護を回避するためのダウングレード手法」を用いると公式ドキュメントで指摘しています。
CISA も、SMSや音声によるワンタイムコードは「フィッシング、SS7、SIMスワップ攻撃に対して脆弱であり、最後の手段としてのみ用いるべき」としています。パスキー自体は強くても、残した弱い経路が狙われます。
出典・参考資料（2件）
ログイン後のセッション乗っ取りです。パスキーは「ログインの瞬間」を守りますが、認証が済んだ後に発行されるセッショントークンやCookieを盗まれると、そのセッションを引き継がれる恐れがあります。
Microsoft のインシデント対応チーム（DART）は、「すでに多要素認証を完了した利用者に発行されたトークンを窃取・再生することで、攻撃者は多要素認証の検証を満たし、組織のリソースへのアクセスが許可されてしまう」と報告しています。これはパスキーの欠陥ではなく、認証方式が強くても守備範囲の外にある経路です。
出典・参考資料（1件）
同期元アカウントへの依存です。同期パスキーの安全性は、エンドツーエンド暗号化と、同期元であるクラウドプロバイダ（Apple／Google）アカウントの保護に支えられています。裏を返せば、同期元アカウントの安全性にパスキーの安全性も依存します。
Microsoft は、より厳格な運用として「attestation（使われている認証器の種類を証明させる仕組み）を有効にすると、デバイスバウンドパスキーのみが許可され、同期パスキーは除外される」と説明しており、クラウド同期を許容するかどうかは設計上の判断ポイントになります。
個人利用と企業導入でデメリットの効き方はどう違うか
ここまで挙げたデメリットは、自分が個人の利用者として使うのか、自社サービスに導入する側なのかで、効き方が変わります。自分の立場に当てはめて読み分けてください。
個人利用で効くデメリット
個人の利用者として効いてくるのは、主に端末まわりと設定の手間です。端末を1台しか持たず同期も設定していないと、紛失・故障時にログインできなくなる恐れがあります。複数の端末にパスキーを用意する、同期を有効にする、パスワードなどの予備の手段を残しておく、といった備えが実際の防御になります。
また、AppleとGoogleを併用していると使い分けにひと手間かかり、共用のパソコンでは使いにくい、という点も個人利用で体感しやすいデメリットです。
企業導入で効くデメリット
自社サービスにパスキーを導入する側では、デメリットは「利用者サポートと設計の負担」として現れます。端末を失った利用者をどう復旧させるか（アカウント復旧の動線）、パスキーが使えない利用者にどの代替手段を残し、それをどう弱点にしないか、同期パスキーを許容するか否か、といった判断が必要です。
さらに、採用する認証基盤によってパスキーまわりの対応機能に差があり、復旧や同期の制御をどこまで細かく設定できるかも変わります。
このように、企業にとってのデメリットの多くは、適切な認証基盤を選び、復旧・代替手段・同期の扱いを設計することで補えます。続いて、その具体的な打ち手と、各サービスが備える機能を見ていきます。
企業がデメリットを設計で補う方法（認証基盤の活用）
ここからは、自社サービスにパスキーを導入する企業が、これまで挙げたデメリットを設計で補う方法を解説します。要点は4つです。いずれも、採用する認証SDK・認証基盤の機能で実現できます。
- アカウント復旧の動線を用意する：端末紛失に備え、リカバリーコードの発行、複数パスキーの登録、代替の本人確認手段を組み込む。
- フォールバックを弱点にしない：パスキーが使えないときの代替手段（パスワード・ワンタイムコード等）は残しつつ、それが攻撃の入口にならないよう扱いを設計する。
- 同期パスキーを許容するか決める：利便性（クラウド同期で復旧しやすい）とポリシー（デバイスバウンドに限定する）のどちらを取るかを、サービスの要件に応じて制御する。
- 認証そのものの外側のリスクに備える：ログイン後のセッション乗っ取りなど、パスキーの守備範囲外の経路は、継続的な本人確認など別の手段で補完することも検討する。
これらの打ち手をどこまで細かく設定できるかは、採用する認証基盤によって異なります。以下では、自社サービスへのパスキー導入を支える主な認証SDK・認証基盤を、デメリット対策に効く観点で紹介します。最後の1社は、パスキーを実装する製品ではなく、パスキー導入後にも残るリスクを継続認証で補う別アプローチです。
| サービス名 | Auth0 | Amazon Cognito | Microsoft Entra External ID | PingOne | Keycloak | Uni-ID Libra | DZ Security® |
|---|---|---|---|---|---|---|---|
| パスキー対応 | ●全プランで対応（Free含む） | ●Essentials・Plusで対応（Liteは非対応） | ●サインイン・MFAで対応（サインアップは非対応） | ●FIDO2はPlus以上で対応 | ●26.4以降で正式サポート | ●FIDO全方式に対応（認定取得） | ×継続認証で補完 |
| アカウント復旧の手段 | ●複数パスキー登録（最大20個）・メールで復旧 | ●複数パスキー登録（最大20個） | ●他端末の同期パスキー・管理者による再登録促し | △公式に復旧手順の記載なし | ◎リカバリーコードを組込可能 | △公式に復旧手順の記載なし | －（パスキー非対応） |
| フォールバック／パスワード併用 | パスワード必須（無効化不可） | パスワード等と併用必須 | パスワード付きアカウントが必須 | マジックリンク・OTP等を併用可 | パスワード等と併用可 | パスワード等と併用可 | 継続認証（パスワードレス） |
| 同期・デバイスバウンド制御 | △両型使えるが制御設定の記載なし | △両型使えるが制御設定の記載なし | ◎同期/デバイス固定を管理者が選択 | ◎Backup Eligibility（同期可否の設定）で制御 | △両型使えるが制御設定の記載なし | △公式に記載なし（要確認） | －（パスキー非対応） |
| 提供形態 | クラウド（SaaS）／SDK・API | クラウド（SaaS）／SDK・API | クラウド（SaaS）／SDK・API | クラウド（SaaS）／SDK・API | オープンソース（セルフホスト） | オンプレミス／クラウド | SDK・API（アプリ組込） |
| 詳細情報 | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | オンライン相談を予約 |
※対応状況は2026年9月時点の各社公式ドキュメント等に基づき、プラン・バージョンにより変わります。「フォールバック／パスワード併用」の列は代替手段の扱いを示す事実で、良し悪しの評価ではありません（パスワードを無効化できないことは制約にもなります。本文参照）。「記載なし」は各社公式ドキュメントに明示がなかった項目です。DZ Security®はパスキー非対応で、パスキー導入後に残るリスクを継続認証で補う別アプローチです。導入時は各社の最新情報をご確認ください。
ここで取り上げるのは、パスキーのデメリット対策という観点で絞り込んだサービスです。パスキーに対応する認証SDK・認証基盤を、機能や料金、選び方まで含めて広く比較検討したい場合は、以下の記事もあわせてご覧ください。
パスワードレス認証とは？自社サービスに組み込む生体認証・パスキー対応SDK/APIを機能・料金で比較【選び方も解説】
自社アプリやWebサービスのログインを、パスワードに頼らない方式へ切り替えたいと考える開発・プロダクト部門が増えています。パスワードの使い回しやフィッシングによる不正ログインが後を絶たず、パスキーやFIDO2といったパスワードレス認証が、そ…
1. Auth0（Okta, Inc.）
Auth0 は、Web・モバイル・APIアプリにログイン機能を組み込むための開発者向け認証プラットフォームで、米国 Okta, Inc. の顧客向けID管理（Okta Customer Identity Cloud）の中核にあたります。パスワードレス認証やアダプティブな多要素認証、ソーシャルログイン、SSO を幅広く扱えます。
デメリット対策の観点では、パスキーを段階的に導入できる「プログレッシブ・エンロールメント」（パスワードでログインした利用者にパスキー作成を促す方式）や、1ユーザーあたり最大20個のパスキー登録に対応し、複数端末での備えを作りやすい点が特徴です。
一方で、公式ドキュメントによればパスキーは既存の認証情報を置き換えるものではなくパスワードは残る設計で、パスワードを完全に無効化してパスキーのみにする構成はできません。フォールバック経路が必ず残ることを前提に、その扱いを設計する必要があります。
2. Amazon Cognito（アマゾン ウェブ サービス ジャパン合同会社）
Amazon Cognito は AWS が提供するマネージド型の顧客ID・アクセス管理サービスです。Web・モバイルアプリ向けの会員登録・サインイン基盤（User Pools）で、パスキー／WebAuthn、SMS・メールのワンタイムコード、多要素認証、ソーシャル連携などに対応します。
紛失への備えとして、1ユーザーあたり最大20個のパスキー登録に対応し、複数端末での登録がしやすい点が挙げられます。ログインの構成では、公式のガイドでパスキー（WEB_AUTHN）とパスワードを併記する形になっており、パスキー単独ではなく代替手段と組み合わせる前提です。
ただし、2024年に導入された機能プランのうち下位の Lite プランではパスキーに対応せず、Essentials 以上が必要になるため、採用時はプランの確認が要ります。
3. Microsoft Entra External ID（日本マイクロソフト株式会社）
Microsoft Entra External ID は、自社アプリを一般消費者やビジネス顧客に提供する際の顧客ID・アクセス管理（CIAM）機能を組み込むためのソリューションです。従業員向けの Microsoft Entra ID とは別に「外部テナント」を構成して利用します。
同期パスキーとデバイスバウンドパスキーの両方を管理者側のプロファイルで選べるため、同期の扱いを方針に合わせて制御できます。一方、外部テナントではパスキーの登録画面が標準では用意されておらず、アプリ側で Microsoft Graph の登録APIを使って自前で実装する必要があります。
導入の初期にはメール・ユーザー名とパスワードのローカルアカウントが必要になるなど、実装と運用の負担がある点は把握しておきたいところです。
4. PingOne（Ping Identity）
認証・ユーザー管理・多要素認証を、ノーコードのオーケストレーションで束ねられるのが、Ping Identity の顧客ID・アクセス管理ソリューション「PingOne for Customers」です。
デメリット対策の観点で特徴的なのは、FIDO ポリシーの設定の細かさです。公式ドキュメントによれば、クラウド同期パスキーを許可するか禁止するか（Backup Eligibility）を管理者が切り替えられ、認証器の種類や attestation の要件もポリシーで指定できます。同期の扱いやデバイスバウンドへの限定を設計で制御したい場合に向きます。
ただし、FIDO2 を含む複数の認証方式の利用には上位プラン（Plus 以上）が必要です。
5. Keycloak（オープンソース）
オープンソースで公開され、ライセンス費用がかからない点が選択理由になるのが Keycloak です。Apache License 2.0 で提供されるID・アクセス管理ソフトウェアで、SaaS として販売される製品とは異なり、自社のサーバーやコンテナ環境に構築して運用するセルフホスト型です。
アカウント復旧の観点では、公式ドキュメントにバックアップ用のリカバリーコード（Recovery Codes）を認証フローに追加する手順があり、端末を失った際の復旧導線を自前で組み込めます。パスキーはログインフローの選択肢として追加し、パスワードログインも併用できます。自社で構築・運用する前提のため、設定やアップデートの運用体制が必要になる点は考慮が要ります。
6. Uni-ID Libra（NRIセキュアテクノロジーズ株式会社）
Uni-ID Libra は、NRIセキュアテクノロジーズが自社開発・販売する、BtoCサービス向けの顧客ID統合・認証ソリューション（パッケージ製品）です。企画・要件定義段階からのコンサルティング支援を伴う導入形態で、国内での提供・サポートを受けられる点が特徴です。
FIDO の各方式に対応し、FIDO のユニバーサルサーバ認定を国内で取得しています。パスキーが使えない利用者には従来の認証方式と併用する運用ができるため、対応環境の差を運用で吸収しやすい構成です。ただし、同期とデバイスバウンドの別、対応OS・ブラウザ、端末紛失時のリカバリー手順の詳細は公式ページに明記がなく、要件に合うかは問い合わせでの確認が前提になります。
国内ベンダーのサポートを重視する場合の選択肢です。
7. DZ Security®（株式会社AnchorZ）
DZ Security® は、株式会社AnchorZ が開発した本人認証プラットフォームです。中核技術は「バックグラウンド認証®」で、ログイン時の一回限りの認証ではなく、サービス利用中ずっとバックグラウンドで本人確認を継続する「継続認証」を採ります。顔と声による生体情報と、端末が取得する行動データを端末内で照合する方式です。
DZ Security® はパスキー（FIDO2／WebAuthn）を実装する製品として提供されているわけではありません。
ただし提供元のAnchorZ は、公式ニュース（代表取締役CEO 署名、2025年8月29日公開・2026年5月20日更新）で、パスキーを技術的に優れた方式と認めつつ、その限界も指摘しています。
具体的には、ローカルの認証（顔・指紋）が突破された後は、連携済みの各サービスへの不正ログインの恐れが残ると述べています。また、本人確認が使い始めの一瞬にとどまり、時間の経過や環境の変化をまたぐ確認には対応しないとして、公開鍵基盤に継続認証を組み合わせる構成を提案しています。
パスキー導入後にも残るログイン後のリスクを、認証の外側で補完する考え方の一例として紹介します。
ログイン時点で本人確認を済ませる方式と、利用中ずっと本人確認を続ける方式をどう区別しているかについて、同社の徳山氏はMCB FinTechカタログの取材で次のように述べています。
ご説明するときに、「ログイン認証」と「継続認証」という二つの言葉を使わせていただいています。
ID・パスワードが初めて使われたのは70年ほど前ですが、それ以来ずっと、ユーザーを識別するには使い始める前にIDとパスワードを入力してもらう仕組みでした。パスワードが覚えられないから生体認証にしよう、顔にしよう、指紋にしようと進化してきましたが、いずれも「使い始める前に認証する」ログイン認証である点は変わりません。そして、ログイン認証でセキュリティを高めようとすると、どんどん複雑で分かりにくくなってしまいます。
一方で私たちのバックグラウンド認証®は、言い方を変えると継続認証です。使い始めるときには何もチェックをしませんが、アプリやサービスを使い始めてからフォアグランドで動くアプリやサービスの裏でずっと継続した認証を続けます。
まとめ
パスキーは、フィッシングに強くパスワード管理の負担も減らせる認証方式ですが、万能ではありません。端末の紛失・故障への備え、対応環境の差、共用環境での使いにくさ、エコシステムをまたぐ移行の手間といった注意点があり、「フィッシングに強い」という評価にも、弱い代替手段への誘導やログイン後のセッション乗っ取りといった守備範囲の外のリスクが残ります。
一方で、これらのデメリットの多くは、自社サービスに導入する企業にとっては設計で補えるものです。アカウント復旧の動線を用意し、代替手段を弱点にしない形で残し、同期パスキーの扱いを制御し、認証の外側のリスクにも目を配る。こうした打ち手は、採用する認証SDK・認証基盤の機能によって実現度が変わります。
デメリットを正しく理解したうえで、自社の要件に合う認証基盤を選ぶことが、パスワードレス化を成功させるうえで重要です。
よくある質問（FAQ）
Q. そもそもパスキーとは何ですか？
A. パスキーは、FIDO2／WebAuthn という国際標準にもとづく、パスワードを使わずに指紋・顔認証やPINでログインする認証方式です。サイトごとに公開鍵と秘密鍵のペアを作り、秘密鍵を端末内の安全な領域に保管して、ログイン時に端末内で鍵を解錠して本人を確認します。覚えたり入力したりする文字列がなく、偽サイトでは署名が成立しないため、フィッシングやパスワードの使い回しに強いことが特徴です。
Q. パスキーの顔認証や指紋認証は、写真や高性能カメラ・AIで突破されませんか？
A. 写真やAIで作った顔で生体認証をだませたとしても、それだけで攻撃者の手元の端末からあなたのパスキーを使うことはできません。パスキーの生体認証は、生体情報をサーバーに送って照合するのではなく、あなたの端末内に保管された秘密鍵を解錠するための操作だからです。
鍵を解錠できるのは本人の端末であり、ログインのたびにその端末上で本人の操作が求められるため、攻撃者が用意した別の端末から本人になりすましてログインすることはできない仕組みになっています。
出典・参考資料（2件）
Q. パスキーが1つ破られると、連携しているサービスも全部不正ログインされますか？
A. パスキーはサービスごとに別々の鍵を作るため、あるサービスの鍵だけで他のサービスに不正ログインされることはありません。1つのパスキーは、それを登録した1つのサイトでしか使えないように束縛されています。
ただし、複数端末で使う同期パスキーの場合、同期元であるクラウドアカウント（Apple ID や Google アカウント）が乗っ取られると、そこに同期された複数サービスのパスキーに影響が及ぶ可能性があります。同期を利用するなら、同期元アカウント自体を多要素認証などで強く守ることが重要です。
出典・参考資料（2件）
Q. パスキーに使う指紋や顔のデータが、サービス側に送られて漏れる心配はありませんか？
A. 指紋や顔などの生体情報はサービス側のサーバーには送られず、端末内の安全な領域だけで処理されるため、サービス側から生体情報が漏れる心配はありません。サーバーに届くのは「本人確認に成功した」という結果（デジタル署名）だけで、生体情報そのものは端末の外に出ません。
出典・参考資料（2件）
Q. パスキーを設定したら、パスワードは削除してもよいですか？
A. 多くのサービスではパスキーと並行してパスワードを残せますが、当面は予備の入口として残しておくのが安全です。パスキーを使う端末をすべて失ったときなどに、パスワードが復旧の入口になるためです。削除（パスワードレス化）を選ぶ場合は、複数の端末にパスキーを登録しておく、リカバリーコードや最新の連絡先を用意しておくなど、代わりの復旧手段をそろえてから行いましょう。
Q. 家族と共用しているパソコンでもパスキーは使えますか？
A. 共用パソコンでも、利用者ごとにOSのユーザーアカウントを分けて各自がパスキーを登録すれば使えますが、1つのアカウントを複数人で共有する使い方には向きません。パスキーは個人の端末・アカウントに紐づく仕組みのため、共有すると誰のログインなのかを切り分けにくくなるからです。共有が避けられない場合は、その用途だけ別の認証手段を併用するといった工夫が必要になります。
Q. 指紋認証や顔認証センサーのないパソコンでもパスキーは使えますか？
A. 生体認証センサーのないパソコンでも、スマートフォンを認証器として使えばパスキーでログインできます。パソコンの画面に表示されたQRコードをスマートフォンで読み取り、スマートフォン側で指紋・顔認証を行うことで本人確認が完了します。近くにある端末どうしで承認する仕組みのため、パソコン自体に生体認証機能がなくても利用できます。
出典・参考資料（2件）
Q. 1つのサービスにパスキーを複数登録できますか？
A. 多くのサービスでは1つのアカウントに複数のパスキーを登録でき、複数の端末に登録しておくと1台を失っても別の端末からログインできます。登録できる数の上限はサービスによって異なります。端末の紛失・故障に備える基本の対策として、メインの端末だけでなく予備の端末にもパスキーを登録しておくことが有効です。
法人向けサービスを課題別に探すならMCB FinTechカタログ
MCB FinTechカタログでは、決済・金融・バックオフィス領域の法人向けサービスを課題別に探し、気になるサービスの資料をまとめて請求できます。生体認証・パスキー認証SDKのほかの課題も、あわせてご確認ください。
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
