パスキーのセキュリティが普及するも、リカバリーリスクは依然として残る

Passkeys now handle logins at major platforms with fewer friction points than traditional passwords. The shift reduces phishing success rates in controlled tests. Yet account recovery after device loss still leaves gaps that security teams have not fully closed.

Users debate whether the move from passwords simply relocates the pain. Recovery flows often require older backup methods or trusted contacts that reintroduce the problems passkeys were meant to solve. Early adopters report smoother daily logins, but the moment a phone is stolen, misplaced, or damaged, the convenience advantage evaporates into lengthy support queues and fallback verification processes that feel indistinguishable from legacy password resets. In practice this means the average user must now plan for contingencies that once felt unnecessary, from printing recovery codes on archival paper to designating multiple trusted contacts across different households.

The underlying tension stems from how passkeys bind authentication to hardware. While this binding strengthens security during normal use, it concentrates risk on the device itself. When that device disappears, platforms must balance stringent identity proofing against user frustration, often defaulting to slower manual reviews. These trade-offs shape both consumer trust and enterprise deployment timelines.

Passkey Adoption Hits New Records

Major platforms reported passkey usage numbers rising sharply in the first half of 2026. Google, Apple, and Microsoft each published updated totals showing millions of daily authentications completed without passwords. The numbers reflect steady growth since the FIDO Alliance pushed broader standards in prior years.

Google’s internal metrics indicated that passkey logins on Android and Chrome ecosystems crossed 500 million monthly active users by March 2026. Google’s passkeys announcement detailed early traction inside consumer accounts. Apple reported similar traction inside iCloud Keychain, noting that more than 60 percent of new iPhone users enabled passkeys for Apple ID within weeks of device setup. Microsoft tied its growth to Windows Hello and Azure Active Directory, where enterprise tenants saw passkey adoption climb from 12 percent to 41 percent of sign-ins between January and June. Microsoft Entra passkeys documentation outlines the enterprise rollout path.

Banks and enterprise services began rolling out similar support. Early data from those deployments showed lower support ticket volume for login failures compared with password systems. JPMorgan Chase piloted passkeys for retail banking customers in three U.S. states and recorded a 34 percent drop in account-lockout tickets during the first eight weeks. Salesforce reported that internal employees using passkeys experienced 87 percent fewer help-desk calls related to forgotten credentials or MFA token issues.

Retailers such as Shopify and Target also introduced passkey options at checkout for returning customers. These integrations rely on the same WebAuthn APIs that power consumer platforms, ensuring interoperability across operating systems. Analysts at Gartner estimate that by the end of 2027 more than 30 percent of consumer-facing websites with over one million users will offer passkeys as a default or promoted login method.

Beyond consumer services, government portals in Estonia and Singapore have begun testing passkey login for citizen services. Initial pilots recorded faster completion rates for tax filings and permit applications, though officials caution that recovery procedures for lost devices remain under active development. The U.S. federal government’s login.gov service completed its own internal beta in May 2026, reporting that 42 percent of participants completed enrollment without ever creating a password.

How Passkeys Differ from Passwords and Traditional MFA

パスキーは共有シークレットを公開鍵暗号に置き換えます。登録時にデバイスは一意のキーペアを生成し、秘密鍵をセキュアハードウェアに保存し、公開鍵のみを依拠当事者と共有します。秘密鍵がデバイスから離れることがないため、ユーザーが類似ドメインに騙されて訪問した場合でも、フィッシングサイトは使用可能な認証情報を収集できません。この分離により、関連のないサービス間でパスワードが再利用された場合に成功するクレデンシャルスタッフィング攻撃も防止されます。

従来の多要素認証は、ユーザーが知っているか所有していて傍受可能なものに依存しています。SMSコード、認証アプリ、ハードウェアトークンはすべて、SIMスワッピングやリアルタイムフィッシングを通じて攻撃者がハイジャックできる追加のラウンドトリップを必要とします。パスキーは所有要素と認証セレモニーを、登録されたデバイス上の単一の生体認証またはPINジェスチャーに統合します。Googleの開発者向けドキュメント は、この暗号化バインディングが攻撃者がフィッシングできる共有シークレットの必要性をどのように排除するかを説明しています。

ユーザーエクスペリエンスも向上します。パスキーログインは、ユーザーがFace IDまたは指紋で確認すると通常2秒以内に完了します。パスワードマネージャーは依然として長い文字列を自動入力し、サイト固有の特殊文字ルールを処理する必要があります。FIDO Allianceによる比較テストでは、同じサイトでパスワード＋TOTPフローからパスキーに切り替えた場合、タスク完了時間が62％短縮されたことがわかりました。

速度だけでなく、パスキーはVerizonの年次データ侵害調査によると、消費者の80％を悩ませるパスワード再利用の脆弱性を排除します。暗号化アテステーションにより、依拠当事者はパスキーが本物のセキュアエレメントから発信されたことを検証できるため、単純なパスワードやSMSでは得られない追加の保証層を提供します。

実際の復旧ワークフローとその摩擦

AppleのiCloud Keychain復旧は、ユーザーが選択した復旧キーまたは信頼できる連絡先のサークルに依存します。ユーザーが復旧キーを紛失したデバイス内にのみ保存しており、信頼できる連絡先に連絡できない場合、Appleは数日かかるアカウント復旧リクエストを必要とします。その間、アカウントはFind MyやiMessageを含むすべてのサービスでロックされたままになります。Apple Storeサポートのない地域のユーザーは、ビデオ検証が集中チーム経由でルーティングされるため、さらに遅延が発生します。

Googleは同様の「アカウント復旧連絡先」機能に加え、28文字の印刷コードを提供します。このコードは一度だけ生成されますが、多くのユーザーはそれをスクリーンショットするか、紛失した電話に同期された同じパスワードマネージャーに保存します。デバイスとマネージャーの両方がなくなると、サポート担当者はレガシーID検証の手順をユーザーに案内する必要があります。ある文書化されたケースでは、オーストラリアの地方在住のユーザーが、家事で復旧コードを保持していた唯一のハードウェアが破壊された後、完全復旧まで11日間待たされました。

エンタープライズシナリオではさらに別のレイヤーが加わります。ハードウェアセキュリティキーにバインドされたパスキーを使用する企業環境では、復旧はITサービスデスク経由でルーティングされることがよくあります。空港にノートPCを置き忘れた従業員は、交換用キーがプロビジョニングされ登録されるまで翌営業日まで待つ場合があります。一部の組織は従業員ごとに事前登録済みのキーを2つ発行することでこれを軽減していますが、これにより調達コストが2倍になり、小規模チームが予算を組むことの少ないキー管理オーバーヘッドが発生します。

クロスプラットフォームの世帯では複雑さがさらに増します。単一のストリーミングアカウントを共有する家族がiOSとAndroidの両方のデバイスにパスキーを登録した場合、一方のプラットフォームからアカウントを削除しても、もう一方の古いレコードが自動的に削除されないことに気づくことがあります。その結果生じる不一致は、正当なユーザーを苛立たせる「不明なデバイス」プロンプトを繰り返し引き起こし、社会工学攻撃中に攻撃者にさらに多くの攻撃対象を提供する可能性があります。

代替認証アプローチとの比較

パスキーを評価する組織は、従来のパスワード、SMSベースのワンタイムパスワード、ハードウェアセキュリティキー、生体認証のみのフローと頻繁に比較します。各オプションには、セキュリティ強度、ユーザー利便性、復旧の複雑さにおいて異なるトレードオフがあります。YubiKeyなどのハードウェアセキュリティキーはポータブルでデバイス非依存の保護を提供しますが、依然としてユーザーが物理トークンを持ち運び在庫を管理する必要があります。パスキーはキーを既存のスマートフォンやコンピュータにバインドすることでこの負担を排除します。

暗号化バインディングなしでデバイス上で実行される生体認証システムは速度を提供しますが、センサーまたはそのストレージが侵害された場合、テンプレート盗難にユーザーをさらします。一方、パスキーは生体認証またはPINジェスチャーと、秘密鍵がハードウェア保護されたエンクレーブに存在することを証明するアテステーションを組み合わせます。パスワード＋TOTPセットアップと比較すると、パスキーは2回目のラウンドトリップ送信を完全に排除することで攻撃対象領域を削減します。Carnegie Mellonの研究者による2025年の研究では、1,200人の参加者に対するリアルタイムフィッシング攻撃をシミュレートしたところ、TOTPフローでの成功率が41％だったのに対し、パスキーでは4％未満に低下しました。

消費者および組織への実践的影響

日常の消費者にとって、パスキーへの移行は日常の摩擦を減らしますが、バックアップの衛生に関する新しい習慣を要求します。リカバリーキーを耐火金庫に保管された予備の家の鍵のように扱うユーザーは、デバイス紛失後のよりスムーズな体験を報告しています。逆に、クラウド同期されたパスワードマネージャーのみに依存する人々は、同じ侵害や同期障害が主要およびバックアップの資格情報を同時に削除することを発見するリスクを負います。

組織は資格情報関連のサポート量を測定可能な形で削減できますが、オンボーディングおよびオンボーディング解除プロセスを再設計する必要があります。人事チームはIT部門と連携して、採用時および退職時にパスキーの発行と失効を行うようになり、以前の数十年にわたるシンプルなパスワードリセットワークフローに取って代わります。監査ログも変化します。パスワード変更の追跡ではなく、コンプライアンス担当者は証明メタデータとリカバリー連絡先の更新を確認します。

金融サービスでは特にリスクが高いです。証券会社が長いリカバリー期間中に顧客を失うと、収益と規制上の監視の両方が危険にさらされます。そのため、いくつかの金融機関は、パスキーを一般小売顧客向けに推進しつつ、高額資産顧客向けにパスワードとハードウェアトークンの並行オプションを維持しています。

限界と残存するリスク

パスキーのセキュリティは依然としてデバイスのセキュアエンクレーブの完全性に依存します。サプライチェーン攻撃や高度な物理的アクセスにより、実験室条件下で秘密鍵が抽出される可能性がありますが、そのような攻撃は国家レベルの活動以外では稀です。より一般的なリスクは、アカウントリカバリー時にユーザーがメールやSMSチャネルにフォールバックする場合に発生し、攻撃者はすでにこれらを大規模に侵害しています。

もう一つの限界はエコシステムの断片化です。Appleのエコシステム内で作成されたパスキーは、iCloud経由で同期しない限り、非Appleブラウザでは使用できません。クロスプラットフォームユーザーは同じアカウントに対して複数のパスキーを維持するため、調整されたバックアップがない場合にいずれかが失われる確率が高まります。

プライバシーへの影響も表面化します。各依存当事者が異なる公開鍵を受け取るため、トラッカーによるサービス間の相関は困難になりますが、デバイスメーカーはどのサイトが新しいパスキーを受け取るかについての可視性を依然として保持しています。このメタデータを懸念するユーザーは、クラウド同期の利便性と、デバイスにバインドされエクスポート不可能な鍵の選択肢を比較検討する必要があります。

今後の注目シグナル

標準化されたリカバリー方式のプラットフォーム採用は、夏の終わりまでに予定されている次期製品リリースで確認できるでしょう。これらのアップデートからのリカバリー成功率に関する指標は、ギャップが縮小するかどうかを示すでしょう。規制当局への提出書類も、必要な変更を明らかにする可能性があります。

2026年後半の消費者行動データは、バックアップ方式を有効に保つユーザーの数と、サポートコール量の削減につながるかどうかを示すでしょう。これらの数値は、パスキーセキュリティがデフォルトの体験になるか、多くのアカウントでオプションのまま留まるかを決定します。

開発者は、リカバリー固有の証明要求を導入するWebAuthn Level 3ドラフトを監視する必要があります。ChromeおよびSafariのベータ版での早期サポートは、ベンダーが登録時にリカバリーステータスを表示し、デバイス紛失前にユーザーがバックアップの健全性を理解できるようにする意向を示唆しています。

各セクターにおけるケーススタディ

2026年初頭に、欧州の航空会社が frequent-flyer アカウントにパスキーを導入しました。4ヶ月以内に、同社はパスワードリセットチケットを51%削減し、セルフサービスチェックイン完了を29%増加させました。運用チームは、旅の途中でデバイスを紛失した乗客のためにレガシーバックアップフローを維持していましたが、コールセンターのボリュームが十分に減少したため、6人のエージェントを荷物サービスに再配置できました。

電子カルテポータルを利用する医療提供者は、さまざまな結果を報告しています。臨床医はシフト交代時のパスキーログインの速さを評価した一方で、医師の携帯電話が救急車に置き忘れられた場合の復旧プロセスは煩雑であることが判明しました。ある病院システムでは、バッジアクセスログに連動した24時間の緊急オーバーライドを導入し、認証済みスタッフの平均復旧時間を1時間未満に短縮しました。

多国籍物流企業は、18,000台のフィールドデバイスにわたるパスワードを ruggedized タブレットにバインドされたパスキーに置き換えました。このプロジェクトにより、車両始動時のドライバーログイン時間が19秒短縮され、週あたり約95時間の総生産性向上につながりました。復旧手順は地域のデポに事前配備された予備タブレットに依存しており、予算で重複ハードウェアを許容できる場合に、デバイス紛失の問題を運用上の冗長性で相殺できることを示しています。

FAQ

パスキーを有効にした場合でもパスワードは使用できますか？

ほとんどのサービスでは、ユーザーが明示的に削除しない限りパスワードはフォールバックとして有効のままです。パスワードを保持するとフィッシングリスクが増すため、多くの専門家はパスキーの復旧に慣れたら削除することを推奨しています。

すべてのデバイスとすべてのバックアップコードを紛失した場合はどうなりますか？

その場合、アカウント復旧はプロバイダーのレガシー本人確認プロセスに依存します。成功は保証されず、数日または数週間かかる可能性があります。

パスキーは YubiKey のようなハードウェアセキュリティキーより安全ですか？

どちらの技術も FIDO2/WebAuthn 標準に基づいています。ハードウェアキーは単に秘密鍵をポータブルなフォームファクターに移動するもので、複数マシン間の復旧を簡素化できますが、物理的な所持が必要です。

政府はパスキー復旧の基準を義務化するでしょうか？

EUでのドラフト規則やカリフォルニア州での法案は、今後3年以内の必須復旧保証を指向しています。ベンダーはすでにコンプライアンスのためにクラウドバックアップ機能を準備しています。

動きの速い技術関連のストーリーを追うチームは、ソースノート、会議の文脈、フォローアップ質問をまとめて保管する場所を必要とすることがよくあります。軽量な AI knowledge base を活用すれば、ニュースサイクルが変わった後でもそれらの要素を簡単に振り返ることができます。