パスキーは本当に安全？合鍵問題とPass-ta-key攻撃の仕組み・現実的な対策

パスキーの利便性を支える「同期機能」と合鍵問題

パスキーは、パスワードを覚えて入力する方式から、端末やパスキーマネージャーが保護する公開鍵暗号ベースの認証へ移行する仕組みです。
フィッシングサイトへパスワードを入力して盗まれるという典型的な攻撃に強く、認証情報をサービス側で大量流出させるリスクも減らせます。
だからといって「パスキーにすれば認証周りの攻撃を一切考えなくてよい」という意味ではありません。
同期型パスキーでは、利便性を高めるための同期基盤、端末の信頼状態、復旧経路、ローカルマルウェアといった周辺要素まで含めて安全性を考える必要があります。

同期型パスキーとデバイス固定型パスキーは同じではない

FIDO Allianceは、パスキーにはクラウドサービスなどを通じて複数端末へ同期される「synced passkeys」と、特定の端末から出ない「device-bound passkeys」があると説明しています。
同期型はスマートフォンの買い替えや複数端末での利用に強く、ユーザーが秘密鍵ファイルを手作業で移行する必要がありません。
一方、デバイス固定型は利便性よりも、鍵を特定の認証器に閉じ込めることを重視した使い方に向きます。

Google Password Managerでは、対応環境で作成したパスキーを同期し、エンドツーエンド暗号化して扱います。
新しい環境で同期済みパスキーを復号する際には、Googleアカウントへログインするだけではなく、Android端末の画面ロックやGoogle Password Manager PINなど、追加のローカル保護が関与します。
つまり「Googleアカウントのパスワードを盗めば、その瞬間にサーバー上の秘密鍵が平文で手に入る」という単純な構造ではありません。

この点は「合鍵問題」を理解するうえで重要です。
同期によって複数端末から同じアカウントのパスキーを利用できる状態は、物理的な鍵が一本だけ存在する状態とは異なります。
しかし、そのことだけを理由に「同期は危険」と結論づけるのも適切ではありません。
実際には、同期データの暗号化、端末の認証、復旧手順、信頼済みデバイスの管理など複数の防御層によって成り立っています。

実務上は、どちらを採用するかを「同期できるか・できないか」だけで決めず、復旧性、利用頻度、端末台数、アカウント価値を並べて考えると判断しやすくなります。
毎日使う一般サービスで毎回物理キーを要求すれば運用負担が増え、利用者が弱い回復手段へ逃げる可能性があります。
逆に、年に数回しか使わない特権管理アカウントなら、多少の手間を受け入れてもデバイス固定型を選ぶ合理性があります。

また「同期型」という言葉から、同じ秘密鍵が無防備に複数端末へコピーされるイメージを持つのは避けるべきです。
実装ごとに同期方式や暗号化、端末認証、復号条件は異なります。
少なくともGoogle Password Managerの説明では、同期パスキーはエンドツーエンド暗号化され、新しい環境での利用には端末ロックや専用PINなどが関与します。
したがって脅威モデルでは、クラウド保管、端末ローカル情報、認証器の鍵、アカウント復旧を分けて考える必要があります。

「合鍵問題」で本当に見るべきなのは信頼の連鎖

同期型パスキーのリスクを考えるときは、「秘密鍵がコピーされるか」だけではなく、どの主体を信頼して認証が成立しているかを見る必要があります。
ユーザー、端末、OS、ブラウザ、パスキーマネージャー、クラウド認証基盤、WebサービスのRelying Partyが、それぞれ別の役割を持っています。
どこか一つの実装や信頼判定に欠陥があれば、暗号アルゴリズムそのものを破らなくても認証フローが悪用される余地が生まれます。

典型的な誤解は「パスキーは秘密鍵だから外へ出ない。
したがってマルウェアにも安全」というものです。
同期型では、秘密鍵を安全に利用するためのメタデータや暗号化された鍵素材、デバイスを識別する鍵、クラウド認証器との通信状態など、認証を成立させる周辺情報が端末側に存在します。
攻撃者は公開鍵暗号を数学的に解読するのではなく、正規クライアントが利用する経路を模倣したり、信頼済み端末として扱われる条件を悪用したりする方向へ攻撃を移せます。

そのため「合鍵問題」は、単なるクラウドバックアップ批判ではなく、認証の信頼境界が端末一台から同期エコシステム全体へ広がる問題として捉えるほうが実態に近いです。
利便性を得る代わりに、ユーザーはパスキーマネージャーのアカウント保護、端末保護、復旧設定、不要端末の削除といった運用も安全性の一部として扱う必要があります。

この信頼の連鎖を棚卸しすると、対策の優先順位も見えます。
たとえばパスキーマネージャーの親アカウントが強固でも、日常利用PCへ情報窃取型マルウェアが常駐していれば、ブラウザ内の認証関連データやセッションが狙われます。
反対に端末を厳格に守っていても、復旧メールが古いまま、不要な端末が登録されたまま、管理者が追加認証なしで認証器を変更できる状態なら別の弱点が残ります。

「一番強い部品だけ」を見て安全性を判断しないことが重要です。
認証システムの安全性は、最も弱い回復経路や管理経路に引っ張られます。
利用者側では端末・親アカウント・復旧情報、サービス側では登録・変更・削除・セッション発行までを一続きのライフサイクルとして管理すると、合鍵問題を過度に恐れず、かつ過信もしない現実的な運用になります。

同期機能のメリットを捨てれば安全になるわけではない

高い安全性が必要な環境では、FIDO2対応のハードウェアセキュリティキーなど、デバイス固定型の認証器を使う選択肢があります。
これは同期パスキーとは異なるリスク特性を持ち、クラウド同期経路を減らせることが利点です。
ただし、紛失や故障時の復旧、予備キーの保管、全利用者への配布、PIN管理など、新しい運用課題が生まれます。

個人利用で「すべてのパスキーを同期禁止にする」ことが常に最適とは限りません。
端末紛失時にアカウントへ戻れず、弱いSMS復旧やサポート窓口の本人確認へ依存するなら、全体として安全性が下がることもあります。
重要なのは、アカウントの価値と攻撃リスクに応じて、同期型とデバイス固定型を使い分けることです。

たとえば日常的な一般サービスでは、同期型パスキーの利便性とフィッシング耐性の恩恵が大きいでしょう。
一方、管理者アカウント、暗号資産、機密情報へアクセスできる特権アカウント、標的型攻撃を受けやすい利用者では、ハードウェアセキュリティキーや強化保護プログラムなど、より強い防御層を追加する価値が高まります。

デバイス固定型へ寄せる場合は、紛失時の手順を先に決めておく必要があります。
予備キーをどこへ保管するか、退職者や異動者のキーをどう失効させるか、災害や出張時に主キーへアクセスできない場合の例外手順をどうするかまで決めないと、緊急時に弱い本人確認へ迂回してしまいます。
認証器を強くしても、例外運用が弱ければ防御効果は薄れます。

企業なら、通常ユーザーは同期型パスキー、管理者や特権操作はデバイス固定型、という段階的な設計も可能です。
重要操作だけステップアップ認証を要求すれば、日常の利便性と高リスク操作の保護を両立しやすくなります。
すべてを一種類の認証器へ統一するより、資産価値に応じて認証強度を変えるほうが運用上は現実的です。

パスキーの強みは今も大きい

Pass-ta-keyのような研究が出たからといって、パスキーがパスワードより危険になったわけではありません。
パスキーはサイトごとに異なる鍵ペアを使い、サービス側には公開鍵だけを登録します。
偽サイトへ入力する共有秘密がないため、従来型のフィッシングやパスワード使い回し攻撃を大きく減らせます。

Googleも、Google Password Managerのパスキーシークレットをエンドツーエンド暗号化し、サーバー側だけではユーザーになりすませない設計を説明しています。
問題になるのは、この強い基本設計の周辺にある端末、同期、復旧、ユーザー確認、実装上の信頼境界です。
したがって対策の方向性も「パスキーをやめてパスワードへ戻す」ではなく、パスキーの強みを維持しながら周辺の弱点を減らすことになります。

従来のパスワードでは、攻撃者が同じ秘密文字列を偽サイトから盗み、別の場所で再利用できることが大きな問題でした。
パスキーでは、サイトごとの公開鍵資格情報とオリジンに結び付いた認証が使われるため、その攻撃モデルを大きく崩せます。
Pass-ta-key研究が注目されるのは、まさに通常のフィッシングが難しくなった結果、攻撃者が端末内部や認証基盤の実装へ焦点を移しているからだと考えられます。

その意味では、Pass-ta-keyはパスキーの失敗を示すというより、攻撃面の移動を示す研究です。
防御側も、ユーザー教育だけに依存した「怪しいURLを見抜く」対策から、端末健全性、認証器ライフサイクル、クラウド側の信頼状態、WebAuthn検証、異常検知まで広げる必要があります。
認証方式が強くなるほど、周辺の運用と実装が相対的に重要になります。

Pass-ta-key（Pass the Key）攻撃の手口

2026年にUnit 42が公開したPass-ta-key研究は、Google Password Managerの同期パスキーとChrome、Windows上のTPMを組み合わせた環境を対象に、侵害済み端末上のマルウェアから認証フローを悪用できる可能性を示しました。
ここで重要なのは、攻撃の前提としてすでに被害者のWindows端末上でマルウェアが動作していることです。
遠隔の攻撃者がメールアドレスだけを知っていれば成立する攻撃でも、パスキーの暗号方式を直接破る攻撃でもありません。

最初の前提は「端末がすでに侵害されている」こと

研究では、ChromeがWindows上に保持する同期パスキー関連データから、被害者がどのサービスでパスキーを使っているかを列挙できることが示されています。
そこには認証先、ユーザー名、credential identifier、暗号化された秘密鍵に関する情報が含まれます。
研究環境では、これらの情報へのアクセスに管理者権限の昇格を必要としない点が問題になりました。

しかし、暗号化された秘密鍵を見つけたことと、そのまま使えることは同義ではありません。
攻撃の核心は、秘密鍵の暗号を力ずくで解くことではなく、Google Cloud Authenticatorが信頼済み端末からの正規要求だと判断するためのデバイス識別経路を悪用する点にあります。

Pass-ta-keyでは、Chromeが利用するTPMバックのデバイス識別鍵に関連する情報をマルウェアが利用し、正規のChromeに似た形で署名処理を呼び出します。
その署名を使ってクラウド認証器へアサーション要求を送り、正規の認証応答を得るという流れです。
Relying Partyから見れば、最終的に届くアサーションは暗号学的には正しいため、「偽のパスワードを見破る」ような単純な検知では防げません。

ここを省くと、一般利用者へ必要以上の不安を与えます。
研究が示すのは、未侵害の端末に対して遠隔からパスキーを直接読めるという話ではありません。
まずマルウェアが被害端末上で実行される必要があり、その足場を使ってChromeやWindowsの認証関連状態へ接触します。
したがって、初期侵入を防ぐソフトウェア更新、マルウェア対策、不要な実行ファイルを開かない運用は、依然として重要な防御です。

一方、「すでにマルウェアがいるなら何でもできる」と片付けるのも適切ではありません。
研究の価値は、管理者権限や端末ロック解除を必要とせず、特定の信頼境界を悪用してパスキー保護アカウントへ到達できる可能性を具体化した点にあります。
マルウェア侵入後の被害をどこまで限定できるかという、二段目の防御設計が問われています。

Pass-ta-keyは「秘密鍵を平文で盗む」だけの攻撃ではない

この攻撃を「クラウドから秘密鍵をダウンロードする攻撃」とだけ説明すると本質を外します。
研究で示された一つ目のPass-ta-keyは、被害端末を利用してクラウド認証器に正規の処理をさせることがポイントです。
攻撃者は被害者の端末上で動くマルウェアを足場として、デバイス識別鍵による署名を取得し、クラウド側へ信頼済みクライアントとして要求を送ります。

このため、端末がオフラインになった後も無条件で使い続けられる「盗んだ万能秘密鍵」を得るケースとは区別する必要があります。
初期のPass-ta-keyでは、認証のたびに被害端末側の処理が必要になる構造が含まれます。
研究ではさらに、この制約を減らすSilver Pass-ta-keyや、同期パスキーを抽出可能な形にするGolden Pass-ta-keyも示されています。

この違いはインシデント対応にも影響します。
平文の秘密鍵ファイルが単純に盗まれたなら、その鍵を失効して再登録することが中心になります。
しかし正規のクラウド認証器へ攻撃者が要求を通していた場合は、端末の信頼情報、セッション、登録済み認証器、クラウド側の状態まで確認しなければ再発経路を残す可能性があります。

さらに、攻撃者が狙う対象はパスキーそのものだけではありません。
ブラウザ内のCookieや既存セッションが盗めれば、パスキー認証を再実行せずにアカウントへ入れる場合があります。
パスキー導入後の監視では「パスワード漏えいがないから安全」とせず、認証後のセッション窃取や端末侵害も同じ優先度で扱うべきです。

User Verificationの扱いが重要になる

WebAuthnでは、ユーザーが端末を操作したことを示すUser Presenceと、PINや生体認証などによる本人確認を示すUser Verificationが重要な要素です。
研究では、通常のPass-ta-keyで得られるアサーションは暗号学的に有効でも、User Verificationを必須にしてUVフラグを適切に検証するRelying Partyでは攻撃が失敗するケースが示されました。

逆に、サービス側がUser Verificationを「preferred」にしていたり、requiredと指定していても返却されたUVフラグを厳格に確認していなかったりすると、防御が弱くなります。
つまり、パスキーを導入しただけでは十分ではなく、WebAuthnの検証ロジックを正しく実装することが必要です。

この点はサービス提供者にとって特に重要です。
パスキーは強い認証器を提供しますが、サーバー側が「署名が正しいか」だけを見て本人確認状態を無視すれば、期待した多要素性を失う可能性があります。
challenge、origin、rpId、credential、counterや拡張情報、UP/UVフラグなど、仕様で求められる検証をライブラリやIdPの推奨方法に沿って実施する必要があります。

サービス側の設定では、userVerificationの指定と、実際に返された結果の検証を分けて考えます。
「requiredを送ったから本人確認済み」と決めつけず、サーバーが受け取ったauthenticator dataを検査してUVフラグを確認する必要があります。
要求と検証の両方が揃って初めて、期待したUser Verificationの保証に近づきます。

また、すべてのサービスで常にUV必須が最適とは限りません。
リスクの低い操作では利便性を優先し、高リスク操作だけUV必須とする設計もあります。
ただし、その場合は「どの操作に強い本人確認が必要か」を明確にし、認証レベルが不足したまま管理操作へ進めないようにします。
決済、認証器変更、復旧情報変更、機密データのエクスポートなどは特に慎重な扱いが必要です。

Silver Pass-ta-keyはユーザー確認の迂回を狙う

Silver Pass-ta-keyでは、既存のUser Verification鍵をそのまま破るのではなく、クラウド認証器側に登録されているUV鍵の状態を操作し、攻撃者が制御する新しい鍵を正規のUV鍵として受け入れさせる経路が研究されています。
これにより、攻撃者は被害者端末がその場で稼働していなくても、User Verification済みとみなされるアサーションを得られる状態を作れると報告されています。

この攻撃が示すのは「生体認証そのものが破られた」ということではありません。
指紋や顔のテンプレートを盗んで偽造するのではなく、クラウド側が「この署名は端末ロック解除を経た正規のUV鍵によるもの」と信じるための登録・更新プロセスを攻撃する点が重要です。

したがって防御では、ローカルの生体認証強度だけを上げるのでは足りません。
認証器の登録、デバイス追加、鍵更新、復旧、クラウド側の信頼状態変更といったライフサイクル操作そのものを高リスクイベントとして監視する必要があります。

Silver系の教訓は、ユーザー確認を「端末で生体認証が表示されたか」という画面上の体験だけで捉えないことです。
クラウド認証器がどの鍵をUV済みとして信頼しているか、その鍵の登録や更新がどの条件で許可されるかまで含めて本人確認の強度が決まります。

サービス側から見れば、最終的なアサーションが正しくても、その背後の認証器ライフサイクルに異常が起きている可能性を直接把握できない場合があります。
だからこそ、重要アカウントでは新規認証器の追加通知、一定期間の高リスク操作制限、既存認証器による再確認、管理者レビューなど、認証器追加後の防御を設ける意味があります。

Golden Pass-ta-keyが示す「同期資産」の価値

研究ではさらにGolden Pass-ta-keyとして、同期された複数のパスキーを抽出し、別環境で利用可能な形へ持ち出せる攻撃も提示されています。
これが成立すると、単一サービスの認証突破ではなく、被害者が同じパスキーマネージャーで管理している複数サービスへ影響が広がる可能性があります。

ここで再び「同期＝危険」という単純化は避ける必要があります。
同期機能にはエンドツーエンド暗号化やハードウェアバックの保護があり、研究はその保護機構を含む実装の特定の信頼経路を悪用しています。
重要なのは、同期された認証資産が高価値である以上、攻撃者が今後も同期基盤・復旧経路・端末信頼・クラウド認証器の実装を研究し続けると考えることです。

同期資産が価値を持つということは、防御側も「一件の認証異常」を単独イベントとして扱わないほうがよいことを意味します。
同じ端末や同じパスキーマネージャーに関係する複数サービスで不審な動きが出た場合、個別サービスのパスキーだけを交換して終えるのではなく、親アカウントと端末全体を調査する必要があります。

企業のSOCやCSIRTでは、IDログ、EDR、ブラウザ関連イベント、クラウド監査ログを突き合わせることで、単一のサービス侵害なのか、認証資産全体が危険なのかを判断しやすくなります。
同期は利便性を高める一方で、侵害時の調査単位を広げる可能性があるため、監視側もアカウント単位・端末単位の相関分析を意識する必要があります。

何が一般化でき、何を一般化してはいけないか

今回の研究対象は、Google Password Manager、Chrome、Windows、TPMを備えた端末という具体的な組み合わせです。
パスキーという技術全体、AppleのiCloudキーチェーン、Microsoftの実装、すべてのブラウザやOSで同じ攻撃手順がそのまま成立することを示したものではありません。

一方で、同期型パスキー全般に共通する設計上の教訓はあります。
暗号鍵そのものを強く保護しても、鍵の利用を許可する端末識別、クラウド側の認可、復旧、ユーザー確認、鍵登録の更新フローに弱点があれば、攻撃者はそこを狙います。
パスワード時代の「秘密文字列を盗む」攻撃から、パスキー時代の「正規の暗号処理を攻撃者のために実行させる」攻撃へ発想が変わると考えると理解しやすいでしょう。

セキュリティ情報を読む際は、研究対象、必要な前提、検証したバージョン、攻撃者権限、成功条件を切り分けることが重要です。
特定製品の実装上の弱点を、WebAuthn標準そのものの破綻へ拡大解釈すると、対策を誤ります。
反対に「特定製品だけの問題」と切り捨てると、同種の信頼境界が他実装にもないかを点検する機会を失います。

利用者が確認すべきことは、使用中のパスキーマネージャーやOS、ブラウザの更新情報、不要端末、見覚えのない認証器です。
サービス提供者は、自社のWebAuthn実装と認証器登録フローを点検します。
研究対象と自分の環境の差を認識したうえで、共通する設計教訓だけを取り入れるのが適切です。

リスクへの具体的な防御アプローチ

パスキー利用者が取るべき対策は、パスキーを捨てることではありません。
今回の研究は、すでに端末上でマルウェアが動いている状況を前提にしているため、まず端末侵害を防ぐ基本対策が重要です。
そのうえで、パスキーマネージャーのアカウント、信頼済み端末、復旧設定、重要アカウントの認証器を分離し、万一の侵害時に被害が連鎖しにくい構成へ近づけます。

個人利用では「同期元アカウント」と端末を最優先で守る

Google Password Managerを使うなら、Googleアカウント自体の保護は重要です。
ただし、単純にパスワードを長くするだけでなく、フィッシング耐性のある認証手段、復旧情報、ログイン済み端末の確認を組み合わせるべきです。
高リスク利用者向けにはGoogleのAdvanced Protection Programがあり、パスキーやセキュリティキーを使った強いサインイン保護を提供しています。

物理セキュリティキーを使う場合は、一本だけに依存しないことも大切です。
紛失すると復旧が難しくなるため、主キーと予備キーを用意し、安全な別場所へ保管する運用が現実的です。
GoogleもAdvanced Protection利用者に、必要に応じてバックアップのパスキーやセキュリティキーを安全な場所へ保管することを案内しています。

また、共有PCや他人が継続利用する端末でパスキーを作らないことも基本です。
Googleのヘルプでも、他のユーザーからアカウントを保護するため、共有デバイスではパスキーを作成しないよう案内しています。
端末の所有関係が曖昧な環境では、ローカルロックを突破されなくても、認証資産の管理境界が不明確になります。

優先順位を付けるなら、まずOS・ブラウザ・パスキーマネージャーを更新し、次に親アカウントのセキュリティ設定と復旧情報を確認し、その後で登録済み端末・パスキーを棚卸しします。
見覚えのない端末や認証器があれば、安全な端末から削除し、必要に応じて全セッションの失効や認証情報の再設定を行います。

バックアップ手段も強度を揃えることが重要です。
強いパスキーを設定していても、簡単に突破できる古いメールアドレスや弱い回復手段が残っていれば、攻撃者はそちらを狙います。
回復性を確保しながら、復旧経路が主要認証を大きく下回らないように設計します。

マルウェア対策はパスキー時代でも最重要

Pass-ta-key研究の前提が端末侵害である以上、OSとブラウザを最新状態へ保つ、正規ソフトウェアだけを導入する、不要な拡張機能を減らす、EDRやアンチマルウェアを適切に運用する、といった基本対策は依然として有効です。
パスキーはフィッシングによる資格情報窃取を大幅に減らせますが、すでに端末内でコード実行を許したマルウェアまで無力化する万能機能ではありません。

特に企業環境では、ブラウザのユーザーデータ領域、資格情報ストア、認証関連プロセスへ不審なアクセスがないかを監視する価値があります。
認証情報を狙うインフォスティーラーは、パスワードだけでなくCookie、セッショントークン、ブラウザプロファイル、暗号化された認証データなどへ対象を広げています。
パスキーを導入した後も「認証情報窃取対策は終わった」と考えず、監視対象を変化させる必要があります。

端末防御では、管理者権限の最小化だけでなく、一般ユーザー権限で動くマルウェアも重大な脅威として扱います。
今回の研究では、特定の操作に管理者権限が不要だったことがポイントの一つでした。
つまり「標準ユーザーだから認証資産は安全」とは限りません。

企業では、アプリケーション制御、EDR、ブラウザ拡張の許可制、ソフトウェア配布経路の管理、端末のハードニングを組み合わせます。
個人では、海賊版ソフトや不審な添付、見知らぬ拡張機能を避け、セキュリティ更新を止めないことが現実的な防御になります。
パスキーの強さを活かすには、そのパスキーを操作する端末を信頼できる状態に保つことが前提です。

重要アカウントはデバイス固定型を組み合わせる

すべてのアカウントでハードウェアキーを必須にすると利便性や復旧性が落ちますが、重要度の高いアカウントだけ分離する方法は現実的です。
たとえばクラウド管理者、ドメイン管理者、パスワード・パスキーマネージャーの親アカウント、金融資産へアクセスするアカウントなどは、FIDO2対応の物理セキュリティキーを使う価値があります。

デバイス固定型パスキーは、鍵が特定の認証器から出ないことが利点です。
ただし、それだけで端末セッションの窃取や管理者権限の悪用まで防げるわけではありません。
認証後のセッションも攻撃対象になるため、再認証、管理操作のステップアップ認証、短いセッション寿命、異常検知などと組み合わせます。

物理キーの導入では、紛失対策を最初に設計します。
予備キーを同じバッグへ入れて持ち歩けば、盗難時に同時に失う可能性があります。
主キーと予備キーの保管場所を分け、定期的に動作確認し、退職や権限変更時には登録を外す運用が必要です。

また、デバイス固定型の導入対象を絞ると管理しやすくなります。
最上位の管理者アカウント、パスキーマネージャーの親アカウント、重要なクラウド環境など「ここを奪われると連鎖被害が大きい場所」を優先します。
すべての一般アカウントを同じ強度へ引き上げるより、リスクベースで段階的に導入するほうが継続しやすいでしょう。

サービス提供側はUVを「要求したつもり」で終わらせない

WebAuthnを実装するRelying Partyでは、User Verificationを必要とするなら、要求パラメータだけでなく、返されたauthenticator dataのUVフラグまで正しく検証する必要があります。
研究では、UVの検証不足によって本来拒否されるべき認証が通るケースが確認され、その後修正された事例も報告されています。

同様に、challengeの一意性と有効期限、origin、rpId、credential ID、公開鍵、署名、ユーザーとの紐づけなどを正しく検証することが欠かせません。
WebAuthnの検証処理は細部が多いため、独自実装を最小限にし、十分に保守されたライブラリや信頼できるIdPの機能を利用するほうが安全です。

さらに、パスキー追加・削除、復旧手段変更、新規端末登録、管理者権限付与といった操作は、通常ログインより高いリスクを持ちます。
これらに既存の強い認証を要求し、ユーザー通知、管理者監査、一定時間の保留、異常時の取り消し手段を用意すると、認証器ライフサイクルの悪用を減らせます。

実装レビューでは、登録と認証を別々に確認します。
登録時にはchallenge、origin、rpId、attestationの扱い、ユーザーへの紐づけを確認し、認証時にはchallengeの再利用防止、署名検証、UP/UVフラグ、credentialの所有者を確認します。
さらに認証器の追加・削除処理が、既存セッションだけで無制限に実行できないかを確認します。

セキュリティテストでは「正常系でログインできる」だけでなく、期限切れchallenge、別origin、UVなし、古いセッション、別ユーザーのcredential、認証器追加直後の高リスク操作など、失敗すべきケースを用意します。
認証は成功パスより拒否パスの品質が重要です。

「パスキー認証成功＝すべて安全」としない

認証成功後にもリスクベースの判定は有効です。
普段と異なる国やネットワーク、初めて見る端末、短時間の大量アクセス、機密設定の変更、複数サービスへの連続ログインなど、通常と異なる行動を検知したら追加確認を求める設計が考えられます。

ただし位置情報やIPだけで機械的にブロックすると、VPN、モバイル回線、出張などで誤検知が増えます。
単一指標に頼るのではなく、端末信頼、セッション年齢、操作内容、過去の行動、認証器の登録時期などを組み合わせることが重要です。

パスキーは「ログイン時の本人確認」を強くしますが、ログイン後の認可まで自動的に安全にするわけではありません。
高額送金、認証器追加、APIキー発行、管理者変更など、被害が大きい操作には別の承認や再認証を設けると防御層を増やせます。

リスクベース認証を導入する場合は、パスキー成功を強いプラス要素として扱いながらも、端末や行動の異常を無視しない設計が適切です。
たとえば新規端末から管理設定を変える場合だけ再認証を要求し、通常の閲覧では追加操作を求めないようにすれば、利便性を保ちながら高リスク操作を守れます。

セッション管理も重要です。
長期間有効なセッションを多数端末に残せば、認証方式が強くても盗まれたCookieが弱点になります。
機密サービスでは、セッションの失効機能、全端末ログアウト、端末ごとのセッション表示、重要操作前の再認証を用意すると、認証後の攻撃に備えられます。

侵害を疑ったときの優先順位を決めておく

見覚えのないパスキー、端末、ログイン通知があった場合は、まず安全な別端末から親アカウントのセキュリティ状態を確認し、不審な端末や認証器を削除します。
同時に、端末がマルウェアへ感染している可能性を考え、感染疑いの端末から重要な認証変更を続けないことが大切です。

その後、重要サービスのセッション失効、復旧情報の確認、管理者権限やAPIキーの見直し、必要に応じたパスキー再登録を行います。
企業では、端末隔離、EDR調査、IDログとクラウド監査ログの突合、侵害期間の特定まで含めたインシデント対応へ接続します。

重要なのは、パスキーを削除してパスワードへ戻すことを最初の対策にしないことです。
侵害端末や盗まれたセッションが残ったままなら、認証方式を戻しても別経路から再侵害される可能性があります。
まず侵害の足場を取り除き、その後に認証資産を再構築する順序が基本です。

復旧の順序を事前に文書化しておくと、慌てて感染端末からパスワードやパスキーを変更する失敗を減らせます。
安全な別端末の確保、親アカウントの保護、端末隔離、セッション失効、重要サービスの確認、認証器再登録という流れを想定し、企業なら連絡先とエスカレーション先も決めておきます。

被害範囲の確認では「ログイン成功履歴があるか」だけでなく、認証器の追加、復旧情報変更、APIトークン作成、メール転送設定、管理者権限変更なども確認します。
攻撃者は一度入った後に永続化手段を作ることがあるため、認証イベントだけを直しても完全復旧にならない場合があります。

利用者と管理者で対策の責任範囲を分ける

一般利用者ができることは、端末を更新する、信頼できないソフトウェアを避ける、共有端末へパスキーを登録しない、親アカウントを強化する、見覚えのない端末やパスキーを確認する、といった運用です。
サービス側のWebAuthn検証不備を利用者が直接修正することはできません。

一方、サービス提供者や企業IT管理者は、User Verificationの厳格な検証、認証器登録フローの保護、ログ監視、端末ポリシー、特権アカウントのdevice-bound運用など、より広い対策を取れます。
両者を混ぜて「ユーザーが気をつければ安全」とまとめると、設計側の責任を見落とします。

この分担を明確にすると、対策が具体化します。
利用者向けには「端末更新」「共有端末へ登録しない」「見覚えのない端末を削除する」など、本人が実行できる項目を案内します。
開発者向けにはUV検証やchallenge管理、運用者向けにはEDRやログ相関、経営・管理部門向けには特権アカウントのポリシーと復旧手順を割り当てます。

一つのチェックリストを全員へ配るより、役割別に責任を分けたほうが抜け漏れを減らせます。
パスキーの安全性は、暗号技術だけでなく、人と運用と実装の協調で決まります。

結論は「パスキーを過信しない」ではなく「守る場所が変わった」

パスキーは、パスワードの使い回し、偽サイトへの入力、サービス側のパスワード漏えいといった長年の大きな問題を減らします。
その価値はPass-ta-key研究が出ても変わりません。
一方で、攻撃者が狙う場所は、共有秘密そのものから、端末、同期基盤、信頼判定、認証器ライフサイクル、セッションへ移ります。

個人利用では、同期型パスキーを便利に使いながら、親アカウントと端末を強く守ることが基本です。
高リスクなアカウントでは、物理セキュリティキーなどのデバイス固定型を併用し、復旧手段も含めて設計します。
サービス提供側では、WebAuthnの仕様に沿った厳密な検証と、ログイン後のリスク制御を徹底します。

パスキーを「絶対に破れない鍵」と見るのではなく、「フィッシング耐性の高い認証方式を、端末と同期エコシステム全体で安全に運用する仕組み」と捉えると、合鍵問題とPass-ta-keyの位置づけが明確になります。
安全性を高める近道は、パスキーを避けることではなく、どの信頼境界が攻撃され得るかを理解し、アカウントの重要度に応じて防御層を追加することです。

今後は、パスキー普及によってフィッシングやパスワードリスト攻撃が減る一方、端末侵害、セッション窃取、認証器登録、クラウド同期の信頼境界を狙う攻撃が相対的に目立つ可能性があります。
防御側は「パスワードを強くする」という単一施策から、端末・ID・認証器・セッションを横断する設計へ移る必要があります。

利用者にとっての実践的な結論はシンプルです。
パスキーは引き続き使う価値が高く、特にパスワードよりフィッシング耐性を高められます。
そのうえで、重要アカウントだけは追加防御を施し、端末と親アカウントを強く守り、異常時にすぐ復旧できる準備をしておくことが、利便性と安全性を両立する現実的な方法です。

運用を始めるときは、まず自分のアカウントを「一般」「重要」「最重要」のように三段階へ分けると、対策を選びやすくなります。
一般アカウントでは同期型パスキーを中心に利便性を確保し、重要アカウントでは親アカウントの保護やセッション監視を強化します。
最重要アカウントではデバイス固定型のセキュリティキー、予備キー、管理操作前の再認証、復旧手順の文書化まで行います。
すべてに最高強度を要求するより、被害の大きさに合わせて防御を厚くするほうが継続しやすい設計です。

また、パスキー関連の脆弱性情報が出たときは、見出しだけで「パスキー終了」と判断せず、攻撃成立条件を確認します。
対象OSとブラウザ、必要なマルウェア権限、同期方式、User Verificationの条件、ベンダー側の修正状況を確認すれば、自分の環境への影響を切り分けられます。
研究で実証された事実と、将来起こり得る一般論を分離して読むことが重要です。

企業では、認証基盤の変更をセキュリティ製品の導入だけで終わらせず、ログ設計やインシデント対応まで更新します。
パスキー導入後に監視すべきイベントとして、新規認証器登録、認証器削除、新規端末、UV失敗、復旧経路変更、セッション発行、特権操作を定義し、EDRの端末イベントと突き合わせます。
こうすることで、パスワード漏えいアラート中心だった監視から、パスキー時代の攻撃面へ対応できます。

最終的に、安全性を左右するのは「パスキーという部品が強いか弱いか」だけではなく、その部品をどの端末で、どの同期基盤で、どの復旧経路と組み合わせ、サービス側がどのように検証するかです。
強い認証方式を正しく実装し、侵害時に被害を局所化できる運用まで整えて初めて、パスキーの利点を最大限に活かせます。

さらに、復旧訓練も有効です。
予備キーが実際に使えるか、安全な別端末から親アカウントへ戻れるか、不審端末を削除する手順を担当者が理解しているかを定期的に確認します。
緊急時に初めて手順を探すと、弱い例外対応を選びやすくなります。
個人でも、予備認証手段の場所と復旧情報を年に一度見直すだけで、紛失時の混乱を減らせます。

パスキーの採用判断では、攻撃事例の有無だけでなく、従来のパスワード運用と比べてどの攻撃を減らせるかも評価します。
新しい攻撃面が存在しても、フィッシングや使い回しを大幅に減らせるなら全体リスクは下げられます。
重要なのは、残るリスクに合わせて端末防御と運用を更新することです。

その視点が重要です。