パスキーのセキュリティとは？フィッシングに強い理由と導入時の注意点を徹底解説

パスキーのセキュリティは何が強いのか

パスワードや OTP と違い、偽画面へ秘密を入力させる前提を減らせます

パスキーのセキュリティを理解するには、まず従来の認証がどう破られるかを思い出す必要があります。パスワード、SMS 認証、メール OTP は、最終的に利用者が何かを入力したり転送したりする前提で成り立っています。攻撃者はその性質を利用して、偽ログイン画面、AiTM、callback phishing、ヘルプデスクなりすましで認証情報を抜き取ります。つまり従来認証の弱点は、秘密の値が人間の手で動くことです。

パスキーでは、秘密の値をそのまま利用者が読み上げたり、コピーしたり、再入力したりする場面を減らせます。FIDO Alliance が繰り返し説明しているとおり、passkey は偽サイトへそのまま持ち出せる固定 secret を前提にしないため、典型的なフィッシングに対して強くなります。ここが、既存の フィッシング対策とは？ や MFAプッシュ爆撃とは？ とつながるポイントです。人の注意力だけに頼らず、認証方式の前提から攻撃面を減らす方向へ寄せられます。

ただし、パスキーは「何も考えずに入れれば安全になる魔法の手段」ではありません。強いのは passkey そのものの性質であって、運用全体ではありません。端末紛失時の回復経路、例外アカウント、弱い fallback、管理者の break-glass 手順が残ると、攻撃者はそこを狙います。だから passkey の導入は、方式の置き換えだけでなく、弱い回復経路を減らす設計とセットで考える必要があります。

『MFA があるから十分』ではなく phishing-resistant かどうかを見てください

企業の認証設計では、「MFA を入れているから大丈夫」と考えがちです。しかし SMS OTP、メール OTP、push 通知だけの MFA は、依然として social engineering に弱い面があります。利用者がコードを読み上げたり、通知を許可したりする余地があるからです。NIST SP 800-63B でも、phishing-resistant authentication を区別して考える必要が示されています。

その意味でパスキーは、MFA の一種として雑に理解するより、偽サイトに秘密を入力しない前提へ寄せる認証と見た方が実務的です。既存の クレデンシャルスタッフィングとは？ や MFA未適用アカウントとは？ が示すように、攻撃者は常に弱い認証経路を狙います。passkey の価値は、その弱い経路を一部の高権限アカウントから先に減らせることにあります。

企業導入でつまずきやすいポイント

企業導入で最も多い失敗は、passkey を UI の改善案件のように扱うことです。利用者体験の向上は重要ですが、セキュリティ上の主眼は攻撃面を減らすことにあります。したがって、導入判断では「どの業務システムへ先に適用するか」「高権限アカウントをどう先行移行するか」「弱い fallback をいつまで残すか」を先に決める方が失敗しにくくなります。

もう一つ大きいのは端末対応差分です。会社貸与端末、BYOD、共有端末、VDI、業務ブラウザ制約など、実際の利用環境はきれいにそろっていません。ここを確認しないまま始めると、「一部の管理者だけは従来認証」「特定部門だけは SMS 例外」という運用が固定化しやすくなります。すると passkey の導入そのものは進んでいても、最も狙われやすい例外経路が残ることになります。

回復手段が弱いと、導入後も social engineering に負けます

セキュリティ上の本当の難所は、本人確認と回復手段です。端末を紛失した、社員が異動した、役員アカウントを引き継ぐ、という場面では必ず例外が発生します。このときに「ヘルプデスクへ電話すれば解除できる」「SMS へ戻せる」「メールリンクで再登録できる」といった弱い回復経路が残っていると、攻撃者はそこを狙います。つまり passkey 本体が強くても、回復手段が弱ければ全体としてはまだ弱いのです。

既存の コールバックフィッシングとは？ や BECとは？ が示すように、攻撃者は人を通じて例外を引き出します。passkey 導入では、本人確認の方法、ヘルプデスクの解除権限、管理者アカウントの回復フローまで含めて設計しなければ、狙われやすい穴は残ります。

高権限アカウントから先に入れる方が効果を感じやすいです

全社一斉導入が理想に見えても、実務では高権限アカウントから始めた方がよいケースが多いです。管理者、経理承認者、IdP 管理者、外部公開サービスの運用者など、攻撃者が乗っ取ると被害が大きい利用者層へ先に passkey を入れると、防御効果がはっきりします。そのうえで一般利用者へ広げる方が、例外経路の管理も整理しやすくなります。

逆に、一般利用者からだけ導入して管理者を後回しにすると、移行途中の長い期間、最も狙われるアカウントだけ古い認証が残ることがあります。導入順序は UX だけでなく、被害が大きいアカウントから攻撃面を減らす観点で決めるのが合理的です。

導入時に見落としやすい設計論点

パスキーの導入設計で見落としやすいのは、IdP 側のポリシーと業務アプリ側の認証フローが一致していないことです。SaaS では passkey を受け付けるが、自社アプリの一部は旧認証のまま、という状態は珍しくありません。この差分があると、利用者は複数の認証方式を覚え続ける必要があり、結局は弱い経路へ依存します。

また、端末貸与ポリシーがそろっていない組織では、passkey の保存先や共有端末の扱いも論点になります。共有端末や作業者交代が多い現場では、個人端末前提の設計をそのまま持ち込めません。だからこそ、導入記事ではなくセキュリティ記事として passkey を扱うときは、どの利用者類型へ、どの認証方式を、どの例外条件で許すかを明文化する必要があります。

FIDO Alliance の enterprise 向け資料でも、rollout は技術だけでなく運用・教育・回復手段を一体で考えるべきと整理されています。パスキーは方式として強くても、導入設計が曖昧だと「一部では使えるが、結局パスワードも残る」状態へ戻りがちです。強い方式を強いまま使うには、例外の期限と縮小計画まで先に決める必要があります。

委託先や共有端末のように『個人端末前提ではない利用者』を先に洗い出す必要があります

パスキーを deploy するときに詰まりやすいのは、実は標準的な社員利用より、委託先、共同作業端末、交代勤務、窓口業務のような個人端末前提ではない利用者類型です。こうした利用者を後回しにすると、結局は例外運用だけが先に増え、導入後も古い認証が残ります。だから設計論点としては「誰が最も使いにくいか」を最初に洗い出し、その人たちの回復や引き継ぎをどう成立させるかを先に決めた方が、全体の移行が崩れにくくなります。

企業利用の記事でよく抜けるのは、この利用者類型の差です。一般社員向けの成功例をそのまま高権限アカウントや委託先へ当てはめると、運用現場が困って例外運用へ戻りやすくなります。パスキーのセキュリティを高く保つには、使いにくい利用者に合わせて弱い fallback を増やすのではなく、利用者類型ごとに運用を分ける必要があります。

同期型 passkey と高保証アカウントをどう分けるか

一般利用者向け rollout と高権限アカウント向け運用は、同じ設計にしない方が安全です

最近の passkey 議論では、端末間で同期される multi-device credentials が一般利用者向けに広く受け入れられています。これは rollout のしやすさという点では大きな利点ですが、企業で高権限アカウントまで同じ設計に寄せるかは別問題です。経理承認者、IdP 管理者、SSO 設定変更者、外部公開サービスの運用者などは、一般利用者より被害が大きくなりやすいため、回復手段、端末要件、本人確認の強さを一段上げて考える方が安全です。

FIDO Alliance の 2025 年 white paper でも、enterprise では「誰でも使いやすい rollout」と「高保証アカウントの扱い」を分けて考える前提が強調されています。つまり passkey の導入では、「全員同じ UX に揃えること」より「どの利用者群でどこまで厳しくするか」を先に決める方が実務的です。とくに権限の高い利用者は、同期型 passkey の利便性だけでなく、紛失時の復旧、端末交換、特権作業時の追加確認まで含めて設計した方が、導入後の例外が減ります。

これは既存の AIエージェントの過剰権限 や サービスアカウントのセキュリティ と同じで、権限が高い主体ほど recovery path の強度を別に考えるべきという話です。passkey も同様に、利用者全員へ同じ認証設計を当てはめるのではなく、業務影響の大きさで運用強度を分ける方が、結果として安全に広げやすくなります。

attestation や端末管理をどこまで求めるかは、業務影響と例外運用の重さで決めます

passkey の議論では、技術的な強さだけでなく「その passkey がどの端末から来たのか」「管理対象端末なのか」をどこまで確認するかも論点になります。すべての業務で厳密な端末保証を求めると rollout が進みにくくなりますが、逆に何も見ないと、高権限アカウントと一般利用者の差がなくなります。ここでは、全社一律の厳しさを目指すより、重要システムだけ管理対象端末や追加確認を要求する方が現実的です。

つまり passkey 導入は、「導入できるか」ではなく「どこまで強く運用するか」の設計です。端末保証や attestation を万能条件として入れるのではなく、どのシステム、どの利用者、どの業務でそれが必要なのかを切り分けると、過剰な例外や無期限の fallback を減らしやすくなります。

移行計画で残しやすい弱い認証経路をどう閉じるか

パスワード only 画面や旧 SSO 入口を一覧化しないと、passkey は広がっても attack surface は減りません

passkey 導入で見落としやすいのは、新しい認証方式を増やすことに集中し、古い認証導線を閉じる計画が後ろへずれることです。利用者向け main login だけ passkey 化しても、古い admin login、委託先 portal、legacy SSO 入口、VPN login がそのままなら、攻撃者はそちらを狙います。つまり導入計画では、「どこへ passkey を入れるか」と同じくらい、「どの弱い login surface をいつ閉じるか」を決める必要があります。

ここで役立つのが、会社のログイン画面洗い出し の考え方です。passkey 導入は認証方式の置き換えですが、現実には公開されている login page の整理が伴います。一覧化せずに導入だけ進めると、実装は進んだのに古い入口だけ残るという逆転が起きやすくなります。だから passkey は identity project だけで閉じず、login surface の縮小計画と一緒に進める方が安全です。

特にブランドや子会社が多い組織、委託先が複数ある組織では、古い認証面が残りやすくなります。導入の KPI を「passkey 有効化数」だけにすると、実際の attack surface は減っていないのに、進んだように見えてしまいます。「何を有効化したか」と「何を閉じたか」をセットで見る方が、セキュリティ記事としても実務に合っています。

ヘルプデスク解除と break-glass を分けないと、例外運用が恒久化しやすくなります

passkey 導入後に必ず残るのが例外運用です。端末紛失、役員交代、出張中の端末破損、業務委託者の一時利用停止など、現場には例外が発生します。このとき、日常的なヘルプデスク解除と、本当に緊急の break-glass を同じ手順で運用すると、便利さのために例外が広がります。これは MFA の例外運用と同じで、緊急用のつもりの導線が常用されるのが危険です。

したがって移行計画では、通常の本人確認フロー、管理者承認付きの再登録、緊急時の break-glass を分けて設計した方がよいです。普段使いの support flow へ簡単な回復経路を置きすぎると、passkey の強さは結局その回復経路に引きずられます。導入を成功させるには、認証方式の強さだけでなく、戻り道をどこまで狭くするかを先に決めてください。

利用者教育は『passkey の使い方』より『古い認証に戻さない判断』まで含めて行います

パスキー導入で見落とされやすいのが教育内容です。多くの組織は登録方法やログイン方法は説明しますが、「怪しい support に誘導されても旧認証へ戻さない」「電話で OTP を教えない」「端末交換時は正規の再登録手順に従う」といった例外時の判断までは十分に伝えていません。しかし攻撃者が狙うのは、通常利用より例外時です。したがって教育では、passkey を使う平時だけでなく、passkey が使えない時に何をしてはいけないかまで含めた方が安全です。

ここまで設計できると、passkey の導入は単なるログイン改善ではなく、弱い認証経路の整理へつながります。方式の強さ、例外運用、教育を同時に設計することで、導入後も古い認証へ戻りにくい運用が作れます。

逆にここを曖昧にしたまま rollout すると、導入率は上がっても incident 時には旧認証へ戻る判断が先に起きやすくなります。passkey の価値を保つには、平時だけでなく例外時の判断基準まで事前にそろえておくことが重要です。

認証導線の見直しを ASM診断 PRO で始めるなら

ASM診断 PRO は passkey 自体を発行したり、IdP の認証方式を直接制御したりする製品ではありません。ただ、passkey 導入で重要なのは「どの login page を先に置き換えるべきか」「どの古い認証面を残しているか」を把握することです。外から見える login page、管理画面、古いサポート導線が曖昧なままだと、導入しても弱い認証経路を閉じ切れません。

ASM診断 PRO を使って外部公開資産を棚卸しすると、passkey を優先導入すべき login surface を見つけやすくなります。たとえば、古い SSO 画面、ブランドごとに残ったログインページ、委託先が運用する管理画面、staging の認証導線などは、導入優先度を決める材料になります。つまり passkey のセキュリティは認証方式の話だけでなく、どの公開ログイン面を残しているかの話でもあります。

既存の 会社のログイン画面洗い出しとは？ や 管理画面・開発環境の露出リスクとは？ と合わせて読むと、passkey を導入すべき対象の洗い出しと、残してはいけない古い認証面の整理を一つの流れで考えられます。方式だけを強くするのではなく、公開ログイン面そのものを減らす観点があると、導入効果は大きくなります。

パスキーを入れて終わりにしないためには、外から見える認証導線を見続け、弱い fallback が残っていないかを確認する必要があります。ASM診断 PRO はその起点として、どの login page が今も公開されているかを整理しやすく、移行計画を現実の公開面へ落とし込みやすいです。まずは外から見える認証面をそろえ、どこから古い認証を縮小するかを決めてください。

よくある質問（FAQ）

パスキーを入れればフィッシング対策は終わりですか

いいえ。パスキーは強い方式ですが、弱い fallback、管理者例外、回復手段が残るとそこが狙われます。導入後の運用設計まで含めて考える必要があります。

SMS 認証やメール OTP はすぐ廃止すべきですか

一斉廃止が難しい場合もありますが、無期限で残すのは避けるべきです。残すなら対象、期限、代替手段を明確にし、段階的な縮小計画を持ってください。

高権限アカウントから先に導入する理由は何ですか

攻撃者が最も狙うのは被害を広げやすいアカウントだからです。管理者や承認者から先に passkey へ寄せると、防御効果が分かりやすくなります。

端末紛失時の回復手段で注意すべき点は何ですか

電話一本やメールリンクで簡単に戻せる運用は危険です。本人確認、承認者、再登録手順を事前に定義し、弱い回復経路を常設しないことが重要です。

どの記事と合わせて読むと理解しやすいですか

認証攻撃の背景は MFA未適用アカウント、MFAプッシュ爆撃、クレデンシャルスタッフィング、フィッシング対策 がつながります。

まとめ

パスキーのセキュリティを理解するうえで重要なのは、単なるログインの便利機能ではなく、偽ログイン画面へ秘密を持ち出しにくい認証方式だと捉えることです。パスワード、SMS、メール OTP が人の入力や転送を前提にするのに対し、パスキーはその前提自体を減らせます。そのため、フィッシングや認証情報使い回しに対して強い土台を作りやすくなります。

ただし、方式が強くても運用が弱ければ全体はまだ弱いです。端末紛失時の回復手段、管理者例外、無期限に残る旧認証、端末対応差分を放置すると、攻撃者は結局そこを狙います。だから passkey の導入では、高権限アカウントから優先し、回復 runbook と fallback 縮小計画を先に決める必要があります。導入でつまずく組織ほど、「どの login 面を先に置き換えるか」「どの弱い認証経路をいつ閉じるか」を明文化した方が前に進みます。

さらに、passkey の導入効果を高めるには、外から見える認証面そのものを見直すことが欠かせません。公開 login page、古い admin 画面、委託先の認証導線が残っていれば、強い方式を一部へ入れても攻撃面は残ります。方式の強さ、運用の強さ、公開面の整理、この三つをそろえて初めて、パスキーは実務のセキュリティ強化として機能します。まずは外から見える認証導線を洗い出し、どこから passkey へ寄せるべきかを確認するところから始めてください。