パスキーとは？メリットや概要を解説|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2025年03月21日更新日時: 2026年08月02日

パスキーは、パスワードを少し便利にする機能ではありません。フィッシングでIDとパスワードを盗まれ、SMSや認証アプリのワンタイムコードまでリアルタイムで奪われる時代に、認証そのものを作り直すための技術です。

セキュリティ対策Labではこれまで、多要素認証(MFA)とは？メリットや必要性を解説や中間者攻撃(AiTM攻撃)とは？多要素認証で防げない理由と対策を解説で、従来型MFAの重要性と限界を扱ってきました。2026年時点では、議論の焦点は「MFAを入れるかどうか」から、「そのMFAがフィッシングに耐えられるか」に移っています。

英国NCSCは2026年4月、サービスが対応している場合はパスキーを推奨し、対応していない場合は従来型の2段階認証を使うという方針を示しました。米CISAも、FIDO/WebAuthnを広く利用可能なフィッシング耐性認証として位置付けています。日本でも、証券口座の不正アクセスや金融機関をかたるフィッシングが深刻化し、金融庁はログイン時・取引時・出金時の多要素認証に加え、パスキー認証などフィッシングに耐性のあるMFAの必須化が進められていると説明しています。

本記事では、パスキーの仕組み、パスワードやOTPとの違い、海外公的機関の評価、国内外の導入事例、企業の情報システム部門が導入時に注意すべき点を整理します。

パスキーとは？フィッシング耐性MFAとしてのサマリー

パスキーは、FIDO2/WebAuthnを基盤にしたパスワードレス認証で、秘密鍵を端末や認証器側に保持し、サービス側には公開鍵を登録する仕組みです。
従来のパスワードやSMS認証、TOTP、プッシュ承認は、AiTM攻撃やリアルタイム型フィッシングで盗まれたり中継されたりする可能性があります。
パスキーは認証先のドメインと暗号的に結び付くため、偽サイトに誘導されても正規サービス向けの認証として成立しにくい点が大きな強みです。
英国NCSC、米CISA、NIST、Microsoft、Google、FIDO Allianceなどは、従来型MFAからフィッシング耐性MFAへの移行を強く打ち出しています。
企業導入では、同期型パスキーとデバイス固定型パスキーの使い分け、紛失時の復旧、共有端末、退職者対応、フィッシング可能な予備手段の扱いが重要です。
パスキーは万能ではなく、端末侵害、セッション窃取、ヘルプデスクを狙うソーシャルエンジニアリング、回復手続きの悪用には別の対策が必要です。

観点	パスキーの特徴	情報システム部門での意味
認証方式	公開鍵暗号を使ったFIDO2/WebAuthnベースの認証	パスワードの保管・再利用・漏えいリスクを減らせる
フィッシング耐性	認証先ドメインと鍵が結び付く	偽サイトでID、パスワード、OTPを入力させる攻撃に強い
MFAとしての位置付け	端末所持と生体認証・PINなどのユーザー検証を組み合わせる	適切に実装すればフィッシング耐性MFAとして扱える
主な方式	同期型パスキー、デバイス固定型パスキー	一般社員と高権限管理者で使い分けが必要
導入効果	不正ログイン、パスワードスプレー、リスト型攻撃のリスク低減	Microsoft 365、Google Workspace、VPN、特権IDから優先導入しやすい
残るリスク	端末侵害、復旧手続きの悪用、セッション窃取、ソーシャルエンジニアリング	EDR、条件付きアクセス、端末管理、回復フローの厳格化が必要
国内での必要性	証券口座乗っ取り、金融機関フィッシング、SaaS不正ログインが増加	顧客向けサービスと社内ID基盤の双方で検討が必要

パスキーは「パスワードを覚えなくてよい機能」ではない

パスキーを説明するとき、「指紋や顔認証でログインできる便利な仕組み」と言われることがあります。利用者向けには間違いではありません。ただ、企業の情報システム部門がそれだけで理解すると、導入判断を誤ります。

パスキーの本質は、認証に使う秘密情報を人間が覚えたり、サーバーへ送ったりしない点にあります。パスワード認証では、利用者が入力したパスワードをサービス側で照合します。サーバー側では通常ハッシュ化されますが、漏えいすれば総当たり攻撃や他サービスでの再利用攻撃につながります。利用者が同じパスワードを複数サービスで使っていれば、一つの漏えいが別のサービスの侵害に連鎖します。

パスキーでは、端末やセキュリティキーが秘密鍵を保持し、サービス側には公開鍵だけが登録されます。ログイン時には、サービス側が出したチャレンジに対して端末側が署名を返し、サービス側が公開鍵で検証します。秘密鍵そのものはサービスへ送られません。偽サイトにパスワードを入力させる従来のフィッシングと相性が悪いのは、この構造があるためです。

利用者に見える画面は「顔認証でログイン」「指紋でログイン」「端末のPINでログイン」です。しかし、裏側ではパスワードやOTPとは別の認証モデルに切り替わっています。ここを押さえないと、パスキーを単なるUX改善機能として扱ってしまいます。

なぜ従来型MFAだけでは足りなくなったのか

MFAが不要になったわけではありません。むしろ、MFAなしの業務アカウントは今でも危険です。問題は、MFAの方式によって守れる範囲が大きく違うことです。

セキュリティ対策Labのワンタイムパスワード(OTP)とは？種類・メリット・注意点をわかりやすく解説でも触れているように、OTPは固定パスワードだけの認証よりは強い仕組みです。パスワードが漏れても、追加のコードがなければログインしにくくなります。

ただ、近年のフィッシングは、盗んだパスワードを後で使うだけではありません。攻撃者は偽ログインページをリアルタイムで正規サービスと中継し、被害者が入力したID、パスワード、OTP、プッシュ承認をその場で使います。これがAiTM攻撃やリアルタイム型フィッシングの嫌なところです。利用者本人は正しい認証手続きをしているつもりでも、その認証結果が攻撃者のセッション取得に使われます。

サイト内でも、中国語圏 PhaaSが日本を標的にサイバー攻撃-PayPay・JA銀行・楽天証券等400超テンプレートでリアルタイム MFA 突破で、日本の金融・決済・ECサービスを狙うテンプレート化されたフィッシングの広がりを扱いました。この種の攻撃では、利用者に正しいOTPを入力させること自体が攻撃フローに組み込まれています。

さらに、多要素認証(MFA)を回避しMicrosoft 365へ不正アクセスするフィッシングサービス Rockstar 2FAやハッカーグループがSoundCloud(サウンドクラウド)やCrunchbaseへのサイバー攻撃を主張-Oktaへのビッシングかのように、Microsoft 365やOktaなどのID基盤を狙う攻撃でも、MFAコードやプッシュ承認が狙われています。

この流れを見ると、MFAの導入率だけをKPIにするのは危ういです。SMS、メールコード、TOTP、プッシュ承認は、何もないよりは強い一方で、フィッシング可能な認証要素として見なす必要があります。重要アカウントから順に、FIDO2/WebAuthn、パスキー、ハードウェアセキュリティキーのようなフィッシング耐性のある方式へ移すことが現実的な防御になります。

海外公的機関がパスキーを評価する理由

英国NCSCは2026年4月、サービスが対応している場合はパスキーを推奨し、対応していない場合は従来型の2段階認証を利用するという方向性を示しました。NCSCは、SMSコード、メールコード、TOTP、プッシュ承認を含む従来型MFAは本質的にフィッシング可能だと整理し、FIDO2認証情報、つまりパスキーを含む認証方式は、実際に観測されている一般的な認証情報攻撃に対して従来型MFA以上に安全だと評価しています。

米CISAも、フィッシング耐性MFAの実装を推奨しており、FIDO/WebAuthnを広く利用可能なフィッシング耐性認証として説明しています。CISAの整理で重要なのは、単に「MFAを使いましょう」ではなく、攻撃者が盗めるMFAと盗みにくいMFAを分けている点です。

NISTは、デジタルIDガイドラインSP 800-63B-4を2025年7月に最終化しました。NISTはそれ以前にも、同期可能な認証器、つまりFIDOパスキーのように複数端末へ同期される認証方式について補足ガイダンスを出しています。NISTは、正しく実装された同期型認証器が、復旧のしやすさ、複数端末対応、生体認証などの利便性を備えつつ、フィッシング耐性を持つ認証器として使えると説明しています。

この流れは、政府機関だけではありません。Microsoft Entra IDは2026年9月1日からSMSまたは音声認証を有効にしているユーザーに対してパスキー登録を促す方向へ進み、2027年2月1日にはMicrosoft提供のSMS・音声認証をEntra IDで終了する予定です。Microsoftは、SMSと音声は安全な認証方式とは位置付けられなくなったと説明し、パスキー、Windows Hello、FIDO2といったフィッシング耐性方式への移行を求めています。

Googleも、Google Workspace向けにパスキー対応を一般提供し、1,100万を超えるGoogle Workspace顧客が利用できるようにしたと説明しています。Googleは、パスキーをフィッシング耐性のある認証方式とし、Workspace利用者ではパスワードより40％速くサインインできるとも述べています。2024年時点では、Googleアカウントにおけるパスキー認証が10億回以上、4億以上のアカウントで使われたと公表されました。

FIDO Allianceの2026年調査では、アクティブに使われているパスキーは50億に達し、消費者の90％がパスキーを認知し、75％が少なくとも一部のアカウントで有効化しているとされています。企業側でも、500人以上の組織の意思決定者を対象とした調査で、68％が従業員認証向けにパスキーを展開、試行、または展開中と回答しています。

パスキーの仕組みを現場目線で見る

パスキーの仕組みは、公開鍵暗号です。利用者がサービスにパスキーを登録すると、端末や認証器の中で公開鍵と秘密鍵のペアが作られます。サービス側には公開鍵が登録され、秘密鍵は端末やセキュリティキー、あるいは認証情報を管理するクラウド同期基盤側に保護された形で保持されます。

ログイン時、サービス側はランダムなチャレンジを端末へ送り、端末側は秘密鍵で署名します。サービス側は登録済みの公開鍵で署名を検証します。パスワードのように「秘密の文字列を入力して送る」のではなく、「そのサービス向けの秘密鍵を持っている端末が、正しい相手にだけ署名する」という流れです。

このとき、パスキーはサービスのドメインと結び付いています。利用者が本物そっくりの偽サイトへ誘導されても、その偽サイトは正規サービス用のパスキーをそのまま使えません。ここがフィッシング耐性の中心です。画面が似ているかどうか、人間がURLを見抜けるかどうかに依存しにくい点は、従来型の利用者教育だけでは得られない利点です。

生体認証についても誤解が多いところです。パスキーで顔認証や指紋認証を使う場合でも、通常は生体情報そのものがWebサービスへ送られるわけではありません。端末内で本人確認を行い、秘密鍵の利用を許可するために使われます。利用者にとっては顔や指紋でログインしているように見えますが、サービス側が受け取るのは暗号署名の検証結果です。

パスワード、OTP、パスキーの違い

比較項目	パスワード	OTP・SMS・認証アプリ	パスキー
利用者が覚える情報	必要	パスワードは必要な場合が多い	原則不要
サービス側に登録される秘密	パスワードハッシュ	パスワードハッシュとOTP用の共有秘密など	公開鍵
フィッシング耐性	低い	従来型は中継される可能性がある	正しく実装されれば高い
リスト型攻撃への耐性	低い	パスワード再利用が残る	パスワード再利用の問題を避けやすい
AiTM攻撃への耐性	低い	SMS、TOTP、プッシュは中継・誘導され得る	ドメイン結合により強い
利用者負担	記憶、入力、使い回し管理が必要	端末確認やコード入力が必要	端末ロック解除に近い操作
企業側の運用	リセット対応、使い回し対策が必要	MFA疲れ、端末変更、番号変更対応が必要	紛失時復旧、端末管理、登録統制が必要

現場で誤解されやすいのは、パスキーが「MFAの代わり」なのか「MFAの一種」なのかという点です。答えは実装次第ですが、ユーザー検証を伴うFIDO2認証は、端末や認証器を持っていることと、端末のPINや生体認証で本人確認できることを組み合わせます。英国NCSCも、ユーザー検証がログインに含まれる場合、FIDO2認証は多要素認証を構成すると説明しています。

つまり、パスキーは単に「2段階目を省く機能」ではありません。正しく設計すれば、従来のパスワードとOTPを置き換える、より強い認証要素になります。

同期型パスキーとデバイス固定型パスキーを分けて考える

パスキーには、大きく分けて同期型パスキーとデバイス固定型パスキーがあります。この違いを無視して「パスキーは安全」または「同期されるから危険」と一括りにすると、企業導入の議論が雑になります。

同期型パスキーは、iCloudキーチェーン、Google パスワードマネージャー、Windowsやサードパーティの認証情報管理サービスなどを通じて、複数端末で利用できるようにする方式です。機種変更や端末追加に強く、一般社員や一般利用者向けには現実的です。FIDO Allianceも、クラウド経由で同期されるパスキーを「synced passkeys」、単一端末に留まるものを「device-bound passkeys」と整理しています。

一方、デバイス固定型パスキーは、物理セキュリティキーや特定デバイスに紐付く認証情報です。同期されない分、紛失時の復旧や予備キー管理が必要になりますが、高権限管理者、金融取引、開発環境、ID管理者、役員アカウントなどでは有力な選択肢です。

企業での落としどころは、全員に同じ方式を強制することではありません。一般社員には同期型パスキーを基本にし、管理者や重要部門にはデバイス固定型パスキーやハードウェアセキュリティキーを求める。このあたりが現実的です。端末管理やヘルプデスク体制が整っていない企業で、いきなり全社員に物理キーを配布しても、紛失対応と業務停止の問い合わせで詰まります。

国内サービスでもパスキー移行は進んでいる

国内でも、パスキーは一部の先進企業だけの話ではなくなっています。

LINEヤフーは2026年4月、Yahoo! JAPAN IDのログイン方法をパスキーへ一本化する方針を発表しました。同社の発表では、Yahoo! JAPAN IDではログインユーザーの約90％がパスワードレスログイン、約60％がパスキーを設定しているとされています。長年パスワードレス化を進めてきたYahoo! JAPANがパスキーへ寄せていることは、日本国内の一般利用者向けサービスにとって大きな参考になります。

NTTドコモも、dアカウントの認証方式について、dアカウント設定アプリへのプッシュ通知による認証を2026年4月14日で終了し、より簡単で安全なパスキー認証へ統一すると案内しています。通信キャリアのアカウントは、決済、契約情報、端末購入、ポイント、金融サービスと結び付くため、パスワードやSMSに頼り続けるリスクが大きい領域です。

メルカリも、不正ログイン防止のためにパスキー登録を案内しています。メルカリのようなC2Cサービスでは、アカウント乗っ取りが決済、売上金、配送先情報、本人確認情報の悪用につながり得ます。単なるログイン保護ではなく、利用者の資産と取引信用を守る手段としてパスキーが位置付けられています。

金融領域では、証券口座乗っ取りの急増が大きな転機になりました。金融庁は、実在する証券会社のWebサイトを装った偽サイトなどで窃取したログインIDやパスワードによる不正アクセス・不正取引に注意を呼びかけています。金融庁の公表資料では、2025年1月から11月までの不正取引件数が9,510件に達しており、ログイン時・取引時・出金時・出金先銀行口座変更時の多要素認証や通知サービスの利用に加え、各証券会社等でパスキー認証等のフィッシングに耐性のあるMFAの必須化が進められていると説明されています。

サイト内でも、証券口座の乗っ取りが急増-2カ月半で1454件、被害総額は約950億円超にや著名投資家のテスタ氏、楽天証券の口座が不正アクセスによる乗っ取りの被害で、証券口座を狙うフィッシングと不正取引を扱ってきました。これらの事例は、パスキー導入を「利便性改善」ではなく「顧客資産保護」の文脈で見るべきことを示しています。

Microsoft 365とGoogle Workspaceでは優先度が高い

企業の情報システム部門がパスキー導入を検討するなら、最初に見るべき対象はMicrosoft 365、Google Workspace、IdP、VPN、リモートアクセス、開発者向けSaaSです。ここを侵害されると、メール、ファイル、チャット、SSO連携、クラウド管理画面、ソースコード、顧客情報へ一気に広がります。

セキュリティ対策Labでは、Microsoft 365環境へ8,100万回超のログイン試行-大規模パスワードスプレー攻撃で、Microsoft 365を狙う大規模な認証攻撃を取り上げました。パスワードスプレーやリスト型攻撃では、漏えい済み認証情報と自動化ツールが組み合わされます。MFAがあっても、適用範囲から漏れたレガシープロトコルや非対話型ログイン、古い認証方式が残っていると、そこが抜け道になります。

Google Workspaceについても、Googleはパスキーだけでなく、ログイン後のセッション保護としてDevice Bound Session Credentials、DBSCの取り組みを進めています。これは、認証後のセッションクッキーを端末に結び付け、セッション窃取への耐性を高める考え方です。パスキーで入口を固めても、マルウェアや悪意ある拡張機能、端末侵害によるセッション窃取が残るため、サインイン後の防御も同時に必要になります。

現場感覚でいうと、パスキーはメールアカウントに最初に入れる価値があります。メールはパスワードリセット、取引先とのやり取り、請求書、SaaS通知、社内承認の起点です。メールが奪われると、攻撃者は次のフィッシングメールを社内外へ本物のアカウントから送れます。単に本人のメールが読まれるだけでは終わりません。

パスキーでも防げない攻撃

パスキーは強い認証方式ですが、すべての攻撃を止めるわけではありません。ここを過大評価すると、導入後の穴が残ります。

一つ目は、端末そのものの侵害です。パスキーは秘密鍵を盗まれにくくしますが、端末がマルウェアに感染し、ログイン後のブラウザ操作やセッションクッキー、OAuth同意、クラウド同期情報を狙われると、別の形で被害が出ます。EDR、MDM、端末の暗号化、OS更新、ブラウザ拡張機能の統制は引き続き必要です。

二つ目は、アカウント復旧手続きの悪用です。パスキーを強くしても、本人確認が甘いヘルプデスクやメールだけのリカバリ、SMSだけの復旧手段が残っていれば、攻撃者はそこを狙います。パスキー導入時には、ログイン方式だけでなく、登録、追加、削除、紛失時復旧、退職時削除の流れまで設計する必要があります。

三つ目は、ソーシャルエンジニアリングです。攻撃者がIT部門や取引先を装い、利用者にリモート操作ツールの導入、OAuth同意、端末登録、MFAリセットをさせる場合、パスキーだけでは止まりません。サイト内のGoogleが警告、ShinyHuntersがボイスフィッシング(ビッシング)を起点としてSaaSへ不正アクセスで扱ったように、音声通話を組み合わせる攻撃では、技術的な認証だけでなく、ヘルプデスク手順や本人確認ルールも狙われます。

四つ目は、フィッシング可能な予備手段の残存です。パスキーを導入しても、同じアカウントでパスワード、SMS、メールコード、TOTPが自由に使える状態なら、攻撃者は弱い入口を選びます。パスキーの価値を出すには、少なくとも高リスクアカウントについてはフィッシング可能な認証方法を段階的に制限し、例外を記録・承認制にする必要があります。

企業導入で失敗しやすいポイント

パスキー導入でつまずきやすいのは、技術そのものより運用です。

よくある失敗は、対象アカウントを広げすぎることです。全社員一斉導入は見栄えがよいですが、端末の種類、OSバージョン、ブラウザ、スマートフォンの有無、BYOD可否、共有端末、派遣・委託先、海外拠点などの差分を吸収できないと、ヘルプデスクが止まります。最初は、情シス、管理者、経理、人事、役員、開発者、クラウド管理者など、侵害時の影響が大きい層から始める方が堅実です。

次に、端末紛失時の復旧手段を詰めないまま始めることです。同期型パスキーであれば機種変更時の負担は軽くなりますが、同期アカウントを失った場合や、会社支給端末だけで運用している場合には復旧手順が必要です。予備の物理キーを登録する、Temporary Access Passのような一時アクセス手段を限定利用する、本人確認を複数人承認にするなど、事前にルール化しておくべきです。

共有端末も注意点です。コールセンター、店舗、工場、医療、教育機関では、1台の端末を複数人が使う場面があります。個人のパスキーを共有端末に登録してしまうと、退職時や異動時の削除漏れ、他人による利用、端末内の認証情報管理が問題になります。共有端末では、個人アカウントの使い方、端末ロック、プロファイル分離、FIDO2セキュリティキーの利用などを検討する必要があります。

利用者への説明も軽視できません。「顔認証を会社に登録するのか」「スマートフォンをなくしたら仕事ができなくなるのか」「私物端末に会社の鍵を入れるのか」といった不安は当然出ます。生体情報がサービス側へ送信されるわけではないこと、私物端末利用の範囲、退職時に会社が削除できる情報、紛失時の手続きは、導入前に丁寧に説明した方がよいです。

導入優先度はどこから考えるべきか

パスキーの導入順序は、攻撃者が欲しがるアカウントから考えると分かりやすいです。

最優先は、ID管理者、Microsoft Entra IDやGoogle Workspace管理者、VPN管理者、クラウド管理者、SaaS管理者です。この層は、侵害されると他人の認証設定やアクセス権限を変更できます。ここにSMSやTOTPだけが残っている状態は避けるべきです。可能であればデバイス固定型パスキーやFIDO2セキュリティキーを使い、通常アカウントと管理者アカウントを分けます。

次に、メール、経理、人事、法務、役員、広報、開発者です。経理は不正送金、請求書差し替え、BECの標的になります。人事は個人情報、給与、採用情報を持っています。開発者はソースコード、APIキー、クラウド環境へつながります。役員や広報は、なりすましに使われたときの社外影響が大きいです。

顧客向けサービスを持つ企業では、管理者だけでなく顧客ログインにもパスキー導入を検討すべきです。証券、銀行、決済、EC、チケット、ポイント、通信、自治体サービスなど、アカウント乗っ取りが金銭や個人情報に直結する領域では、パスキーは差別化ではなく基礎対策になりつつあります。

パスキー導入時のチェックリスト

チェック項目	確認すべき内容
対象アカウント	管理者、役員、経理、人事、開発者、顧客向けログインの優先順位を決めているか
認証方式	同期型パスキー、デバイス固定型パスキー、物理キーの使い分けを決めているか
予備手段	パスワード、SMS、TOTPなどフィッシング可能な手段が抜け道として残っていないか
復旧手順	端末紛失、機種変更、退職、異動、アカウントロック時の手順が文書化されているか
端末管理	MDM、EDR、OS更新、画面ロック、暗号化、ブラウザ管理が整っているか
共有端末	共用PCや店舗端末で個人パスキーをどう扱うか決めているか
ログ監視	パスキー登録、削除、復旧、認証方式変更を監査ログで追えるか
ヘルプデスク	本人確認、例外承認、電話でのリセット依頼対応を厳格化しているか
利用者説明	生体情報の扱い、私物端末利用、紛失時対応を利用者に説明しているか
段階移行	パイロット、重要部門、全社展開の順で進める計画があるか

パスキーとゼロトラストの関係

ゼロトラストを掲げていても、認証がパスワードとSMS中心のままでは土台が弱いです。ゼロトラストでは、利用者、端末、アプリ、ネットワーク、場所、リスクを継続的に評価します。その入口になるのがIDです。IDが簡単にフィッシングされる状態では、条件付きアクセスやSaaS統制も後手に回ります。

パスキーは、ゼロトラストにおけるID防御の土台として使えます。特に、管理者操作、重要データへのアクセス、危険な国・地域からのログイン、未知の端末からのログイン、支払い・出金・権限変更といった場面では、パスキーやFIDO2セキュリティキーを条件にする設計が有効です。

ただし、ゼロトラストの文脈でも、パスキーだけで完結しません。端末状態、EDRの稼働状況、MDM登録、準拠ポリシー、セッションリスク、OAuthアプリ同意、データ持ち出し制御まで組み合わせる必要があります。GoogleがパスキーとDBSCを組み合わせて説明しているのも、認証後のセッション保護が重要になっているためです。

情報システム部門への示唆

パスキーは、全社展開ありきで考えるより、被害の大きいアカウントから現実的に入れるべきです。最初の対象は、Microsoft 365、Google Workspace、IdP、VPN、クラウド管理者、経理、人事、開発者が適しています。この層でSMSや音声、TOTPだけに依存している場合、AiTMやビッシング、ヘルプデスクなりすましに弱くなります。

導入時は、パスキーを有効化するだけで満足しないことが重要です。フィッシング可能な代替手段が残っていれば、攻撃者はそちらを狙います。高権限アカウントでは、パスワード、SMS、メールコード、TOTPの利用範囲を絞り、例外を承認制にします。一般社員については、同期型パスキーを活用しながら、登録率、失敗率、復旧件数、ヘルプデスク負荷を見て段階的に拡大します。

復旧フローは、認証方式そのものと同じくらい重要です。電話一本でMFAリセットができる、本人確認が社員番号と生年月日だけ、委託先アカウントの管理者が不明、といった状態では、パスキー導入後も攻撃余地が残ります。パスキー登録・削除・復旧・端末紛失対応は、監査ログと承認フローに乗せるべきです。

利用者教育の内容も変える必要があります。従来の「怪しいURLを見抜きましょう」だけでは限界があります。今後は、「正規のログイン画面でも、電話で指示されて認証操作をしない」「IT部門を名乗る相手にMFA登録やパスキー登録を求められたら別経路で確認する」「パスキーの追加・削除通知が来たら報告する」といった、認証操作そのものを守る教育が必要になります。

顧客向けサービスを持つ企業では、パスキー導入をセキュリティ部門だけの判断にしない方がよいです。ログイン体験、問い合わせ対応、機種変更、アクセシビリティ、金融・決済時の追加認証、利用規約、補償方針まで関係します。プロダクト、CS、法務、リスク管理、広報を含めて設計することで、導入後の混乱を抑えられます。

よくある質問

Q. パスキーを入れればパスワードはすぐ廃止できますか？

A. 多くの企業では、すぐに完全廃止するより段階移行になります。既存端末、共有端末、委託先、海外拠点、レガシーアプリ、復旧手段が残るためです。ただし、高権限アカウントではパスワードやSMSを例外扱いにし、パスキーやFIDO2セキュリティキーを標準にする設計が望ましいです。

Q. パスキーはMFAですか？

A. ユーザー検証を伴うFIDO2認証では、認証器や端末を持っていることと、生体認証やPINで本人確認することが組み合わされます。英国NCSCも、ユーザー検証がログインに含まれる場合、FIDO2認証は多要素認証を構成すると説明しています。

Q. 同期型パスキーは危険ですか？

A. 危険と一括りにするのは正確ではありません。同期型は機種変更や複数端末利用に強く、一般利用者や一般社員には現実的です。一方で、同期アカウントの保護や復旧手続きが重要になります。高権限アカウントでは、デバイス固定型パスキーや物理セキュリティキーを使う方が適する場面があります。

Q. パスキーはAiTM攻撃を完全に防げますか？

A. 正しく実装されたパスキーは、認証情報の中継や偽サイトへの入力に強い方式です。ただし、ログイン後のセッション窃取、端末侵害、OAuth同意の悪用、ヘルプデスクなりすまし、復旧手続きの悪用までは単独で防げません。条件付きアクセス、端末管理、セッション保護、教育、監視と組み合わせる必要があります。

Q. 企業で最初に導入すべき対象はどこですか？

A. ID管理者、Microsoft 365やGoogle Workspaceの管理者、VPN、クラウド管理者、経理、人事、開発者、役員から始めるのが現実的です。顧客向けサービスでは、金融、決済、EC、ポイント、通信など、アカウント乗っ取りが金銭被害や個人情報被害に直結する領域を優先します。

まとめ

パスキーは、便利なログイン機能というより、フィッシング耐性MFAへの移行を支える認証基盤です。SMS、メールコード、TOTP、プッシュ承認は、従来のパスワードだけの認証よりは強いものの、リアルタイム型フィッシングやAiTM攻撃に対しては限界があります。だからこそ、英国NCSC、米CISA、NIST、Microsoft、Google、FIDO Allianceが、フィッシング耐性認証への移行を前面に出しています。

日本でも、証券口座乗っ取り、金融機関をかたるフィッシング、Microsoft 365不正ログイン、SaaSを狙うビッシングの事例が続いています。こうした攻撃は、利用者の注意力だけに頼る対策では追いつきません。ログイン画面が本物に見えるかどうかを人間に判定させるのではなく、認証方式そのものを偽サイトで使いにくい形へ変える必要があります。

とはいえ、パスキーを入れれば終わりではありません。フィッシング可能な予備手段、紛失時の復旧、共有端末、端末侵害、セッション窃取、ヘルプデスクを狙うソーシャルエンジニアリングは残ります。情報システム部門に求められるのは、パスキーを単体機能として入れることではなく、ID基盤、端末管理、監視、復旧手順、利用者教育まで含めて、認証の運用を作り直すことです。