資金について：CypherpunkGuideは監視型広告を一切載せない——広告ネットワークも、トラッキングピクセルも、スポンサー記事もない。運営は透明な収益源による。現在は読者からの寄付、将来は購読と編集方針に合致したアフィリエイト。私たちは広告主ではなく、読者に向き合う。
普段のログインだけを見れば、パスキーはすでに成果を出している。FIDO Allianceの2025年版Passkey Indexによると、ログイン成功率はパスキーが93%、その他の方式が63%。平均所要時間も8.5秒で、その他の方式の31.2秒を大きく下回った。フィッシングにも強い。利用者が入力する使い回し可能な秘密情報そのものがないため、偽サイトに盗み取られないからだ。
難しさが表れるのは、普段のログインではなく復旧時だ。通常のログインでは優れた認証情報でも、その背後にある電話番号、メールアカウント、クラウド事業者、信頼済み端末、紙のコードに依存しているかもしれない。私は2026年8月1日、Google、Apple、Microsoft、GitHub、FIDO、NISTの公式資料または一次資料25件を確認し、各社に同じ故障条件を当てはめた。毎日使うスマートフォン、パソコン、持ち歩くハードウェアキーを失い、別の場所に保管した復旧手段だけが残っているという条件だ。見えてきたのは、一つの「パスキー復旧」ではない。永久に締め出される条件がそれぞれ異なる、二段階または三段階の復旧だった。
したがって、問うべきは「パスキーはSMSによる二要素認証（2FA、パスワードに加えて別の証明を求める仕組み）より安全か」だけではない。フィッシングへの強さでは、パスキーが勝る。だが本当に確かめるべきなのは、同じ失った端末へ戻ることなく、パスキーを保管する側とそのパスキーを受け入れるアカウントの両方を復旧できるかだ。この記事では依存関係を整理し、検索結果に混じり始めたMicrosoft個人アカウントと企業向けEntraの混同を正したうえで、復旧を先に準備する移行手順を示す。読みながら最後のログイン手段を削除してはいけない。
パスキーの復旧には、別々の二つの復旧がある#
パスキーの復旧には、認証情報プロバイダーからパスキーを戻す方法と、利用先のアカウントを取り戻して新しいパスキーを登録する方法がある。担当する会社が異なるため、一方に成功しても、もう一方まで復旧できるとは限らない。
パスキーとは、特定のウェブサイトやアプリで使う暗号学的な認証情報である。ウェブサイトは公開鍵を持ち、端末または認証情報の管理ソフトは秘密鍵を持つ。パスキーが使うウェブ標準のWebAuthnは、その鍵を正規サイトのドメインに結びつける。NIST SP 800-63B-4が、適切に設定されたWebAuthnをフィッシング耐性ありとし、人が入力するワンタイムコードを耐性なしとするのはこのためだ。
一度のログインの背後には、二つの役割がある。
- 認証情報プロバイダーは、パスキーを保存または同期する側だ。iCloudキーチェーンを使うAppleの「パスワード」、Google パスワード マネージャー、Microsoft Password Manager、第三者のパスワードマネージャー、Windows Hello、物理セキュリティキーがこの役割を担う。
- 利用先サービスは、そのパスキーを受け入れるウェブサイトやアプリである。GitHubは利用先サービスだ。GoogleやMicrosoftは、自社アカウント用のパスキーを自社に保存する場合、保管元と利用先の両方になりうる。
今回の資料監査で最初に分かったのは、この役割の違いだ。Apple、Google、Microsoft、GitHubを同じ性質の4列として並べる比較は多い。実際には、ここでのAppleは主に認証情報プロバイダーであり、GitHubは主に利用先サービスである。端末を失ったあと、この違いが効いてくる。
| 認証情報または経路 | 秘密情報の保管場所 | 端末を1台失っても残るか | 毎日使う端末をすべて失った場合 | 主なリスク |
|---|---|---|---|---|
| 同期型パスキー | エンドツーエンド暗号化された認証情報の管理ソフト | 別の端末ですでにログイン済みなら、通常は残る | プロバイダーのアカウントを復旧し、暗号鍵を戻すための確認を通す | 同期型パスキーの復旧がプロバイダーのアカウントに依存する |
| 端末固定型パスキー | 1台のスマートフォン、パソコン、または物理キー | そのパスキーは戻らない。別の認証手段があればアカウントは残りうる | 別の経路で利用先アカウントを復旧し、新しいパスキーを登録する | 認証情報そのものを永久に失う |
| 復旧コード | 紙またはオフラインの安全な保管場所 | 残る | 1回限りのコード、または長い復旧コードを入力する | 盗難、紛失、日常端末と同じ場所への保管 |
| メールまたは電話による復旧 | 別のアカウントまたは携帯電話会社 | 場合による | 先にその連絡経路を復旧する | フィッシング、SIM swap、共通原因による同時喪失 |
FIDOの同期型パスキー導入資料も、この条件を曖昧にしていない。同期すれば端末喪失に耐えやすくなるが、プロバイダーへのアクセスを失ったり、復元時の確認を通せなかったりすることはある。「同期済み」とは、保護された複製が存在するという意味だ。プロバイダーが必ず返してくれるという保証ではない。
毎日使う端末をすべて失ったら、何が起きるか#
毎日使う端末をすべて失った場合、同期型パスキーを戻せるかは認証情報プロバイダー次第である。端末固定型パスキーは戻らない。利用先のアカウントを守るのは、別の場所に残した復旧手段だけだ。
この条件を4つの環境へ適用した結果は、ダウンロードできるパスキー復旧監査に残した。これは文書の監査であり、実際のアカウントを締め出す実験ではない。私は稼働中のアカウントから認証手段を削除していないし、読者も再現のためだけに削除すべきではない。
比較対象は、自分で管理する個人アカウントに限った。Google Workspace、Managed Apple Account、GitHub Enterprise Managed Users、Microsoft Entra IDのように、管理者または組織のIDプロバイダーが管理するアカウントには組織固有の規則があるため、この表の対象外だ。後でEntraの日付に触れるのは、検索結果にある個人向けと企業向けの混同を正すためだけである。
| 環境 | この監査での役割 | 同期型パスキーの復元 | 文書にあるプロバイダー／アカウント復旧の仕組み | 日常端末を失っても復旧できる条件 | 失敗／永久締め出しの境界 |
|---|---|---|---|---|---|
| Google個人アカウント | プロバイダーと利用先の両方 | Googleアカウントに加え、Google パスワード マネージャーのPINまたは条件を満たす使用済み端末 | プロバイダー／Googleアカウント： 復旧情報。条件を満たす個人アカウントでは復旧用の連絡先も追加できる | 失った端末とは独立した復旧経路または連絡先に、少なくとも一つアクセスできる | パスワードマネージャーのPINを復旧できず、そのコレクションの全パスキーをリセットする。利用先ごとに別の復旧が必要になる |
| Apple個人アカウント | 主にプロバイダー | Apple Accountの確認を使うiCloudキーチェーンの安全な復旧 | プロバイダー／Apple Account： 標準のアカウント復旧、登録済みの復旧用連絡先、または任意で設定した復旧キー | 信頼済み電話番号を取り戻せる、または事前登録した連絡先か28文字のキーが失った端末の外にある | 復旧キーを有効にしたのに、信頼済み端末も28文字のキーもなく、Advanced Data Protectionで別途設定され、復旧キーと併用できる復旧用連絡先も使えない |
| Microsoft個人アカウント | プロバイダーと利用先の両方 | 同期先のプロバイダーへログインして復元。Windows Helloや物理セキュリティキーなら端末固定型の場合がある | プロバイダー／Microsoftアカウント： 代替のセキュリティ情報、または25桁の復旧コード | 代替経路へアクセスできる、または25桁のコードをオフラインに保管してある | 2段階認証が有効で代替手段がない。Microsoftはサポートでも回避できないとしている |
| GitHub個人アカウント | 主に利用先サービス | 同期型ならパスキーのプロバイダーが復元する。GitHubは秘密鍵を保有しない | 利用先の個人アカウント： 16個の1回限りのコード、別のパスキー／セキュリティキー、SSHキー、personal access token（PAT）、確認済み端末 | オフラインのコードか別に保管した認証手段が残る。SSH、PAT、確認済み端末は、残っており、かつGitHubが復旧用と認めた場合だけ使える | パスキーも、GitHubが受け付ける復旧手段もない。GitHub Supportはアクセスを復元できない |
表からは、もう一つの問題も見える。「パスキーを使っている」だけでは、どこに保存されたか分からない。Windowsの案内で作った認証情報が、あるときは1台のWindows Helloに、別のときは同期型のパスワードマネージャーに保存されることがある。QRコードを使う操作も、その場だけスマートフォンを借りる場合と、スマートフォンに認証情報を保存する場合がある。復旧を考える前に、利用先サイトのパスキー一覧と、プロバイダー側の認証情報一覧を開こう。サイト名だけでなく、プロバイダーと端末を記録する必要がある。
4つの環境の復旧経路を個別に見る#
4つの環境はいずれも、安全にパスキーを使える仕組みは持っている。締め出しを避けられるかは、保存場所、プロバイダーアカウントの復旧、日常端末の外にある予備手段で決まる。
Google個人アカウント——パスワードマネージャーのPINを確認する#
Google パスワード マネージャーは、Android、Chrome、iPhone、iPadの間でパスキーを同期できる。パソコン、iPhone、iPadで初めてパスキーを作ると、Google パスワード マネージャー専用のPINが作成される場合がある。GoogleのPINに関する資料によると、このPINは新しい端末でパスキーのロックを解除するために使われ、暗号化されたデータをGoogle自身が読めない状態に保つ。
個人のGoogleアカウントへパスキーを追加しても、既存のパスワード、復旧情報、ほかの認証手段が自動で消えるわけではない。Googleアカウントのパスキー案内では、パスキーがログイン時の第2段階も満たせると説明している。つまり、日常のログインは一つのパスキーで済む一方、明示的に削除しない限り、以前の手段は復旧用に残る。
厳しい境界は、PINを忘れた場合だ。Googleは、Google パスワード マネージャーのパスキーを以前使ったAndroid以外の端末からPINをリセットできるとしている。条件を満たす端末をすべて試しても復旧できない場合、資料に示された代替手段は**「パスキーをリセット」**である。これはGoogle パスワード マネージャー内のパスキーをすべて削除する操作であり、各ウェブサイトが新しいパスキーを自動発行する操作ではない。利用先のアカウントを一つずつ復旧し、登録し直すことになる。
多くの解説が一つにまとめる二つの経路を、私は分けて記録した。Googleのアカウント復旧手続きはGmailとGoogleアカウントへのアクセスを戻す。パスワードマネージャーの復旧は、暗号化されたパスキーの集合を開けるようにする。アカウントを取り戻しても、それだけで暗号化された集合を開けるとは限らない。2段階認証で締め出された場合、Googleの問題解決ガイドは、一部の審査に3〜5営業日かかるとしている。Googleは2025年、条件を満たす個人アカウント向けにRecovery Contactsを導入した。ただし利用資格と展開状況に左右されるため、全員が使える保証ではなく追加の選択肢として扱うべきだ。
Apple個人アカウント——iCloudキーチェーンの復旧には条件がある#
AppleはiCloudキーチェーンを、パスワードとパスキーをエンドツーエンド暗号化して同期する仕組みとして設計した。Appleのサーバーは、読める形の記録を保持せずに暗号化済みデータを転送する。Apple Platform Securityは、利用者の端末すべてへアクセスできない場合にも、キーチェーンを復旧できるよう設計されていると明記している。「iCloudにある」という説明だけでは分からない復旧範囲を、より正確に示している。
ただし無条件ではない。Appleのパスキーのセキュリティに関するページによると、全端末を失った場合の復旧では、Apple Accountのパスワード、登録した電話番号へのSMS、端末のパスコードが必要になることがある。復旧用の暗号データを預かるエスクローサービスで試せる認証は10回までで、10回目に失敗するとエスクロー記録が破棄される。「全端末を失っても復旧できる」は、用意された経路の説明であって、回数制限のない保証ではない。
キーチェーンの復旧もApple Accountに依存する。標準の手続きでは、アカウント情報、信頼済み電話番号、端末のパスコード、時間をかけたアカウント復旧が使われる。復旧用連絡先は6桁のコードを発行でき、最大5人まで登録できる。連絡先はアカウントの中身を読めず、本人確認の復旧を手伝うだけだ。
Appleは、アカウント復旧に数日以上かかることがあり、サポートでも待ち時間を短縮できないとしている。当日中の緊急アクセスではなく、最後の経路として扱う必要がある。
任意の復旧キーには、特に強い警告が要る。Appleの復旧キーに関する資料では、28文字のキーを有効にすると標準のアカウント復旧が無効になる。Advanced Data Protection（高度なデータ保護）では復旧キーと復旧用連絡先を併用でき、どちらかでアクセスを取り戻せる場合がある。それでも、アカウントのパスワードが分からず、信頼済み端末がなく、キーを提示できず、設定済みの連絡先も使えなければ、永久に締め出される可能性がある。復旧キーで自分の管理権を強められるのは、守る対象の外に保管した場合だけだ。Apple Notes、iCloud Drive、「パスワード」アプリへ置けば、復旧に必要なものが復旧対象の中に閉じ込められる。Appleも、そうした場所へ保存しないよう警告している。
Apple Accountの物理セキュリティキーは、iCloudで同期するパスキーとは別の機能である。Appleは物理キーを最低2本、最大6本まで登録できるとしている。セキュリティキーの案内には、信頼済み端末と登録したキーをすべて失えば、アカウントから永久に締め出される可能性があるという警告もある。予備キーは、事前に登録し、動作を確かめ、日常端末とは別の場所に置いて初めて役に立つ。
Microsoft——個人アカウントとEntraの廃止日程を混同しない#
Microsoftは同期型と端末固定型の両方のパスキーに対応する。個人向けパスキー案内では、同期型は認証情報の管理ソフトを通じて復元でき、端末固定型は別の認証手段がなければ端末とともに失われると説明している。Microsoft Password Managerは個人用Edgeプロファイル向けに展開中だが、Windows Helloと物理セキュリティキーは端末内だけに残る場合がある。
「Microsoftは2026年9月にSMSを廃止する」という見出しは、助言を誤らせかねないため、Microsoftの資料まで戻って確かめた。2026年9月1日からの展開は、組織が管理するディレクトリであるEntra IDテナント向けの方針だ。SMSまたは音声認証がすでに有効な利用者は、パスキー登録の対象として自動的に有効化され、登録を促される。テナント管理者は一時的にオプトアウトできるが、Microsoftが提供するEntraのSMS・音声配信は2027年2月1日に終了する。Microsoftは別に、個人アカウント向けSMSコードを段階的に廃止するとも説明している。ただし個人向けページに、2026年9月を全員共通の期限とする記載はない。二つを同じ日程として扱うと、個人利用者に存在しない期限で認証手段を外させることになる。
個人アカウントの復旧には別の厳しい境界がある。2段階認証を有効にした状態で代替の確認手段へ一つもアクセスできない場合、通常のアカウント復旧フォームもサポートも助けにならないとMicrosoftは復旧フォームの案内で説明している。一方、Microsoftは事前に生成する25桁の復旧コードを用意している。復旧コードの案内によると、2段階認証を有効にした状態でセキュリティ情報を変更すると、反映に30日かかることがある。コードを作って保管するのは、パスキーの端末を失ったあとではなく、危機の前である。
GitHub個人アカウント——手段は多いが、サポートによる例外はない#
ここで扱うのは、認証情報を自分で管理する個人アカウントだ。GitHubのパスキー資料は、この復旧方法を企業が管理するアカウントへ広げていない。個人アカウントでは、ブラウザでのログイン時に一つのパスキーがパスワードと2FAの両方を満たす。同期型パスキーを戻すのは、その秘密鍵を保存したApple、Google、Microsoft、その他のプロバイダーである。GitHubのパスキー管理ページも、同期済みの認証情報はプロバイダーを通じて復旧するよう案内している。端末固定型のセキュリティキーは、GitHubの一覧に残っていても復元可能にはならない。
GitHubは、その先の復旧手段も明確にしている。復旧方法の資料では、16個の1回限りの復旧コードを発行する。SSHキー（Git操作やサーバー接続で使う暗号鍵）、personal access token（PAT、パスワードの代わりにAPIなどで使う個人用トークン）、確認済み端末も候補になりうる。ただし、以前使えた手段でも復旧に使えない場合がある。たとえば、長く使われていないSSHキーは対象外になることがあるため、使えると決めつけず、状態を確かめる必要がある。GitHubが認める確認済み端末またはSSHキーを使った復旧申請には、最大3営業日かかることがある。
最後の境界は明快だ。個人アカウントで認証情報と復旧手段をすべて失った場合、GitHub Supportは2FAアカウントを復元できない。認証情報を失った場合の案内は、その喪失を永久的なものとしている。パスキーを日常のログインにする前に、コードをオフラインへ保存し、複数の手段を登録すべきだ。
復旧の逆説——強いログインを、弱い予備経路が支える#
復旧の逆説とは、フィッシングに強いログインを、より弱い復旧経路が支える状態である。攻撃者はパスキーではなく、それを置き換えられるメール、電話、サポート手続き、クラウドアカウントを狙える。
だからといって、パスキーが誤りなのではない。復旧の仕組みも認証の一部であり、後ろに付く事務手続きではないということだ。NISTの復旧ガイダンスは、アカウント復旧を認証手段の管理イベントとして扱い、アカウントの保証水準に合う復旧方法を求めている。1回限りの復旧コードは、日常端末から独立させられる点で役立つ。それでも偽サイトに入力すれば、フィッシングには耐えない。
| 復旧経路 | 失った端末から独立しているか | フィッシングに強いか | 向く用途 | 強化する方法 |
|---|---|---|---|---|
| オフラインの復旧コード | 端末外に保管すれば、はい | いいえ | 緊急時のアクセス | 紙または暗号化したオフラインの複製。クラウドだけに置かない |
| 2本目の物理セキュリティキー | 別の場所に置けば、はい | はい | 重要アカウント | 2本を登録して両方を確認し、1本は別の場所へ保管する |
| 同じプロバイダー内の同期型パスキー | 一部のみ | ログイン時は、はい | 日常利用と端末1台の喪失 | プロバイダーの復旧を強化し、外部の手段も残す |
| 復旧用メール | 別アカウントなら、はい | それ自体は、いいえ | 広く使えるアカウント復旧 | 別のプロバイダー、パスキー、独立した復旧手段を使う |
| 電話／SMSによる復旧 | 電話サービスが残れば、はい | いいえ | 互換性のための最後の経路 | 携帯電話会社に暗証番号を設定し、電話番号の脅威モデルで露出を減らす |
| 復旧用連絡先 | 本人とその端末が使えれば、はい | それ自体は、いいえ | Appleまたは条件を満たすGoogleアカウントの復旧 | 慎重に選び、連絡方法と本人確認の手順を確認する |
パスキーの持ち出しと移行は改善しているが、将来の約束を前提に設計してはいけない。FIDOは2026年3月、安全に認証情報を出し入れするためのCredential Exchange Format Proposed Standardを公開した。提案標準が公開されたことは、利用中のプロバイダーが現在すべてのパスキー転送に対応している証拠ではない。別のプロバイダーへ移せると見込む前に、移行元と移行先の両方で、実際のエクスポートとインポート機能を確かめる必要がある。
プライバシー上のトレードオフも明快だ。同期は端末1台の喪失に強い代わりに、復旧をクラウドアカウントへ集中させる。端末固定型のキーはプロバイダーへの依存を減らす代わりに、物理的な紛失の代償を大きくする。自分で運用することと、管理画面の向こうへ信頼を移しただけの状態を分ける点は、主権を5層で点検する方法と同じだ。標語ではなく、想定する相手と起こりうる故障を具体的に決めて選ぶべきである。
復旧を先にする移行手順#
安全な移行は復旧の準備から始まる。保存場所を棚卸しし、プロバイダーの外に予備手段を作り、壊さずに確認してからSMSやパスワードの優先度を下げる。
- アカウントとプロバイダーを分けて書く。 単に「GitHub——パスキー」ではなく、「GitHub——Google パスワード マネージャー」と記録する。同期型、端末固定型、不明のどれかも付ける。不明なら、まだ何も削除しない。
- 最初にプロバイダーのアカウントを守る。 同期型パスキーを戻すには、利用する認証情報プロバイダーのアカウントを復旧し、暗号鍵を開けるための確認を通せなければならない。復旧用メール、信頼済み電話番号、復旧用連絡先、独立した認証手段を更新する。AI時代の脅威モデルと同じく、先に敵を決めて備える。
- そのプロバイダーの外に、復旧経路を一つ作る。 サービスに応じて、印刷した復旧コード、別の場所に置く2本目の物理キー、または別端末に秘密鍵か動作確認済みのバックアップがあり、利用先が復旧用として現在も受け付けるSSHキーを使う。唯一の複製を、守る対象と同じクラウドアカウントへ置かない。
- 何も壊さずに試す。 ブラウザのプライベートウィンドウか別プロファイルでログインを始め、予備手段が選択肢に出ることを確認する。可能なら、状態を見るだけの非破壊的な確認を使う。1回限りのコードを使った場合は使用済みと記録し、直ちに補充するか、保管中の一式を再生成する。訓練のためだけに完全なアカウント復旧を始めたり、主パスキーを削除したり、端末を消去したり、信頼済みセッションすべてからログアウトしたりしない。
- 復元手順をオフラインへ記録する。 プロバイダー名、利用先アカウント、予備手段の保管場所、公式の復旧URLを含める。Bitcoinを初めて保有した後の復旧訓練と同じで、試していないバックアップは、効くという思い込みにすぎない。
- 古い手段の優先度は、アカウントごとに一つずつ下げる。 日常のログインではパスキーを優先する。独立した経路に成功し、サービスが復旧に電話番号を要求しないことを確かめてから、SMSを外す。スマートフォン、パスワードマネージャー、Apple／Google／Microsoftアカウント、セキュリティキーを変更したら、もう一度確認する。
順序を逆にしてはいけない。SMSを先に外し、「予備は後で追加する」と考えると、その間のスマートフォンの紛失、画面の破損、キーの紛失、保存先の選択ミスが永久の締め出しに変わりうる。セキュリティ対策は、同時に失う経路を減らすために行うもので、自分で増やすためではない。
結論——SMSをいま置き換えるべきか#
日常のログインにはパスキーを使え。ただし、別の復旧経路を新しいブラウザで安全に確認できるまで、SMSの優先度を下げるな。フィッシングに強いログインと、一つの端末やクラウドアカウントに依存しない復旧を組み合わせよ。
通常のログインについては、根拠がそろっている。先に挙げたFIDOのデータと、Googleが2024年に報告した4億アカウント、10億回超の認証、ログイン時間50%短縮は、通常利用の結果である。端末を失ったあとの復旧を測った数字ではないことも忘れてはいけない。
端末喪失時の復旧は、一つの製品機能にまとまっていない。Google パスワード マネージャーではPINが要る場合がある。Appleではアカウント復旧、復旧用連絡先、復旧キーのいずれかが関わる。Microsoft個人アカウントには代替のセキュリティ情報と25桁のコードがある。GitHubは復旧コードか、事前登録された別の証明に依存する。「クラウドにバックアップ済み」の一言では、これらの条件は分からない。
失えば最も困るアカウントから始めよ。プロバイダーと利用先を対応づけ、その両方の外に復旧手段を一つ置き、確かめてから次のアカウントへ進め。午後のうちにすべてのサービスで「パスキーを使う」を押すより時間はかかる。それでも、鞄を一つ失っただけで重要アカウントへまとめて戻れなくなる事態を避けながら、フィッシングへの強さを得られる。
よくある質問#
パスキーはSMSによる二要素認証より安全ですか？#
フィッシングへの強さでは、はい。WebAuthnのパスキーは正規サイトのドメインに結びつくため、偽サイトが再利用できるログイン秘密情報を集めることはできません。SMSコードは偽サイトへ入力してしまうことがあり、SIM swapのあとに傍受されることもあります。ただし復旧は別です。失ったパスキーを置き換えるためにSMSを受け付けるサービスなら、その復旧経路にはSMSのリスクが残ります。
スマートフォンを失うと、パスキーはどうなりますか？#
同期型パスキーは、別の端末で認証情報の管理ソフトを復旧し、暗号化されたデータのロックを解除できれば戻る可能性があります。そのスマートフォンだけに保存した端末固定型パスキーは失われます。どちらの場合も、2つ目の認証手段か利用先サイトのアカウント復旧方法がなければ、スマートフォンなしでアクセスを取り戻せません。
Apple、Google、Microsoftは、同期したパスキーを読めますか？#
各社の資料では、パスキーの集合はエンドツーエンド暗号化されるか、プロバイダーが読める形の秘密鍵を受け取らないよう保護されると説明されています。それでもプロバイダーへの依存がなくなるわけではありません。アカウント、同期サービス、復旧規則、暗号化された集合へのアクセスを制御するソフトウェアは、各社が運用しています。
パスキーを追加したら、パスワードとSMS用の番号を削除すべきですか？#
すぐには削除しないでください。先に独立した復旧手段を追加し、何も消さずに新しいブラウザから確かめてください。その後、サービスが許す場合に限り、復旧経路が同じ端末やプロバイダーへ依存していないことを確認しながら、弱い手段をアカウントごとに外すか、優先度を下げます。
すべてのパスキーと復旧コードを失っても、サポートがアカウントを戻してくれますか？#
戻せると決めつけてはいけません。GitHubは、受け付けられる復旧手段がなければ2FAアカウントを復元できないとしています。Microsoftも個人アカウントについて、2段階認証が有効で代替手段へアクセスできない場合、復旧フォームでは対応できないと説明しています。失う前に、独立した認証手段を用意してください。
出典#
