パスキーは「端末を替えても使えるか」まで設計する

パスワードを置き換える仕組み

FIDO Allianceによると、パスキーは公開鍵と秘密鍵の組み合わせを使うFIDO認証情報で、サービス側に保存されるのは公開鍵である。W3CのWebAuthn Level 3も、ウェブアプリがWebAuthnの対象（Relying Party）ごとに公開鍵資格情報を作成し、認証器に結び付けるAPIとして仕様を定めている。

秘密情報をサーバーで共有しないことと、認証情報がサービスのドメインに結び付くことが、フィッシング耐性につながる。

導入の確認対象は「パスキーに対応したか」だけではなく、登録時とログイン時に正しいドメイン、チャレンジ、ユーザー確認をサーバーが検証しているかまで含む。

同期型と端末固定型を分けて考える

FIDO Allianceは、クラウドサービスを通じて複数端末に同期するものを「同期型」、一つの端末やセキュリティキーから出ないものを「端末固定型」と整理している。同期型は端末を替えたときの利用や復旧がしやすく、端末固定型は認証情報のコピーを一つに限定したい環境に向く。

この違いは、便利さと管理条件の選択に直結する。業務サービスで端末固定型を採用するなら、紛失時の予備キーや登録解除の手順を先に用意する。同期型なら、利用するパスキー提供者のアカウント保護と、組織の端末管理方針を確認する。

端末移行には、同じ環境と異なる環境がある

Googleの開発者向け資料は、Androidで作ったパスキーが同じGoogleアカウントにログインしたAndroid端末間で同期される一方、別のOSに同じ形で同期されるとは限らないと説明している。別の端末に保存されたパスキーを使う場合は、QRコードを読み取り、近くにある端末同士を確認して認証するクロスデバイスの経路もある。

確認時には、同じエコシステム内の機種変更、iOSやmacOSをまたぐ移行、会社の管理端末から個人端末への移行を分けて試す。ブラウザとOSの組み合わせ、Bluetoothの近接確認、ログインできないときの表示までが検証対象になる。

復旧経路を、登録と同じ日に試す

Googleは、パスキーだけで新規アカウントを作る場合にも、電話番号やメールなどの復旧方法を確立するよう案内している。サービス側で公開鍵を削除しても、利用者の端末や資格情報管理者にある秘密鍵まで削除されるわけではないため、アカウント画面で登録元を表示し、複数のパスキーを管理できるようにすることも必要になる。

復旧手段が残っていることは、認証を強くすることと別の条件だ。メールや電話のフォールバックを残すなら、その経路にも同じ強度の本人確認を設定し、端末紛失・全パスキー削除・異なるOSからの初回ログインを実際に確認する。