パスワードとパスキーとは何か？
次のシナリオを考えてみてください。午前2時14分、SOCアナリストが認証ログを確認し、過去1時間に数百回のログイン失敗が記録されていることに気付きます。午前2時31分、過去の侵害から盗まれた認証情報を使って1件のログインが成功し、セキュリティスタックはこれを検知しませんでした。
これがパスワードとパスキーの本質的な違いです。パスワードは共有シークレットモデルで動作し、同じ認証情報がデバイスとサーバーの両方に存在します。攻撃者がそのサーバーを侵害したり、認証情報をフィッシングで入手した場合、認証に必要なすべてを手に入れることになります。パスキーは非対称暗号技術によりこの脆弱性を排除します。秘密鍵はデバイスから決して離れず、サーバーに保存される公開鍵は攻撃者にとって暗号的に無意味です。
22,052件のセキュリティインシデントを分析した2025年版DBIRによると、侵害の88%が盗まれた認証情報に関与しています。パスワードは、複雑さの要件や定期的な変更、ユーザートレーニングに関係なく、システム全体の脆弱性を生み出します。
パスキーは、FIDO2プロトコルアーキテクチャを2つの補完的な標準で実装します。1つはブラウザやプラットフォームの認証情報管理を担うW3C Web Authentication（WebAuthn）仕様、もう1つはアプリケーションと認証器間の通信を担うFIDO Alliance CTAP2（Client to Authenticator Protocol）です。これらのプロトコルにより、パスワードの送信を、特定ドメインに紐付いた暗号学的チャレンジレスポンス認証に置き換えます。
パスキーを登録すると、認証器はそのアカウント専用の公開鍵・秘密鍵ペアを生成します。秘密鍵はデバイスのハードウェアセキュリティモジュールやセキュアエンクレーブ内に安全に保管され、ネットワークを通じて送信されることはありません。サーバーには公開鍵のみが登録されます。認証時、サーバーは暗号学的チャレンジを送信し、デバイスが秘密鍵で署名することで、鍵自体を公開することなく所有を証明します。
これらのアーキテクチャ上の違いが、どの攻撃がインフラに成功し、どの攻撃が失敗するかを直接左右します。
パスワードとパスキーのサイバーセキュリティへの関係
パスキーは、侵害の大半を引き起こす認証の弱点に対応します。 NIST Special Publication 800-63BはAAL2でフィッシング耐性のある認証を要求し、AAL3ではそれを必須としています。また、 CISA CPG 2.0はパスキーをフィッシング耐性のある手法として明示的に推奨しています。パスワードは、長さや複雑さ、変更頻度に関係なく、これらの要件を満たすことができません。
データがその理由を裏付けています。2025年版DBIRの調査によると、クレデンシャルスタッフィング攻撃は攻撃ピーク時の認証トラフィック全体の44%を占め、 侵害されたアカウントの80%が他サービスからの認証情報漏洩を経験していました。 ランサムウェアは侵害の44%で確認され、パスワードの使い回しが初期アクセスの入口となっています。2021年のColonial Pipeline攻撃はその好例で、攻撃者は1つの侵害されたVPNパスワードを使ってネットワークにアクセスし、 DOJの発表によれば440万ドルの身代金支払いにつながりました。
パスキーはこれらの攻撃経路を排除します。 FIDO Allianceによれば、パスキーの設計は、公開鍵がサーバーに保存されていてもユーザーデバイス上の秘密鍵がなければ認証できないため、フィッシング、クレデンシャルスタッフィング、大規模なデータ侵害に耐性があります。
具体的な攻撃ベクトルを詳しく見る前に、次の表はパスワードとパスキーがセキュリティチームにとって重要な観点でどのように比較されるかをまとめています。
パスワード vs パスキーの概要比較
パスワードとパスキーの違いは、セキュリティアーキテクチャ、ユーザー体験、コンプライアンス対応、エコシステムサポートに及びます。この比較はFIDO Allianceの調査、NIST標準、Verizon DBIRデータに基づき、各観点を定量化しています。
| Feature | Password | Passkey |
| Authentication Model | 共有シークレット（サーバーが認証情報を保存） | 非対称暗号（サーバーは公開鍵のみ保存） |
| Phishing Resistance | なし；認証情報は任意のドメインに送信される | 暗号学的ドメインバインディングでフィッシングサイトを遮断 |
| Credential Stuffing Risk | 高い；使い回し認証情報が複数サービスで有効 | なし；各認証情報はサービスごとに一意 |
| Login Success Rate | 平均63%（FIDO Alliance Passkey Index） | 平均93%（FIDO Alliance Passkey Index） |
| Login Speed | 平均約27.5秒 | 平均約13.6秒（FIDO Alliance Passkey Index） |
| User Action Required | パスワードを記憶・入力し、MFAを完了 | 生体認証またはデバイスPIN |
| Server Breach Impact | ハッシュ化パスワードがオフライン攻撃に晒される | 公開鍵は秘密鍵がなければ暗号的に無意味 |
| Recovery Method | メールによるパスワードリセット | 同期パスキー、バックアップ認証器、または管理者による復旧 |
| Compliance (NIST AAL2/AAL3) | フィッシング耐性要件を満たせない | フィッシング耐性要件を満たす |
| Platform Support | ユニバーサル | Apple、Google、Microsoftエコシステム；上位100サイトの48% |
以降のセクションでは、これら各観点を詳しく検証し、パスキーが排除を目指すパスワードの脆弱性から解説します。
セキュリティ脆弱性：パスワード攻撃ベクトル
パスワードは、フィッシング脆弱性、クレデンシャルスタッフィング曝露、中間者攻撃による傍受、データベース侵害時の影響という4つの主要な弱点を生み出します。 NIST SP 800-63Bは、FIDO2/WebAuthnの非対称暗号アーキテクチャがパスワードでは実現できないフィッシング耐性認証を可能にすることを確認しています。
- フィッシング攻撃はパスワード認証に対して依然として有効です。 2025年版Verizon DBIRにまとめられた調査によると、ユーザーはトレーニング後も模擬フィッシング演習でリンクをクリックし続けています。ユーザーが攻撃者管理ドメインでパスワードを入力すると、その認証情報は平文で攻撃者に送信され、即座に実際のサービスで試されます。2023年のMGM Resorts侵害はその好例で、攻撃者は ソーシャルエンジニアリングでMFAを回避し、SEC提出資料によれば約1億ドルの損害をもたらしました。
- クレデンシャルスタッフィングはパスワードの使い回しを大規模に悪用します。 Verizonの2025年版Data Breach Investigations Reportによれば、侵害されたアカウントの80%が他サービスからの認証情報漏洩を経験しています。ユーザーは消費者向けサービス、業務プラットフォーム、企業アプリケーション間で認証情報を使い回すのが一般的です。いずれかの消費者サービスが侵害されると、攻撃者は即座にその認証情報を企業の 認証エンドポイントで試行します。
- 中間者攻撃はパスワード送信を傍受します。 MITM攻撃者はユーザーとサーバーの間に位置し、偽のSSL証明書などの手法で通信を傍受します。パスワード認証は本人証明のためにシークレットを送信する必要があり、この送信自体が通信の暗号化に関係なく脆弱性となります。
- データ侵害はハッシュ化パスワードも漏洩させます。 認証データベースにはパスワードのハッシュが保存されており、平文パスワードではありません。この保護は認証情報の侵害を遅らせるだけで防止はできません。データベースにアクセスした攻撃者は、アカウントロックやレート制限を回避してハッシュ化パスワードに対しオフライン総当たり攻撃を実行します。データベースが侵害されると、全ユーザーのパスワードを即時リセットする必要があります。
パスキーは、認証情報の窃取を無効化する暗号アーキテクチャにより、これらの脆弱性を排除します。
パスキーの暗号アーキテクチャ
パスキーが提供するセキュリティ保証は、基盤となる暗号技術の仕組みによります。パスワードが共有値の秘密性に依存するのに対し、パスキーは公開鍵暗号を用い、認証の証明と認証シークレットが本質的に異なるオブジェクトとなります。
認証時、サーバーはWebAuthn APIを介してユーザーの認証器に暗号学的チャレンジを送信します。認証器はデバイス内の秘密鍵でこのチャレンジに署名し、署名済みアサーションをブラウザ経由でサーバーに返します。サーバーは事前登録された公開鍵でデジタル署名を検証します。このチャレンジレスポンス方式により、秘密鍵を公開することなく所有を証明できます。
ドメインバインディングがフィッシング耐性を提供します。 WebAuthnは認証を登録時の特定オリジンドメインに暗号学的に紐付けます。ユーザーが フィッシングサイトで自社ドメインを模倣した場合でも、ブラウザのWebAuthn実装が誤ったオリジンへの認証レスポンス送信を遮断します。この保護はプロトコルレベルで動作し、ユーザーの判断に依存しません。ユーザーが見た目で完全に騙されても、フィッシングサイトは有効な認証レスポンスを受け取れません。
暗号アルゴリズムは政府・企業導入向けにNIST仕様に準拠しています。サポートされるアルゴリズムは以下の通りです：
- 署名操作用のECDSA、RSA、EdDSA各種
- ハッシュ用のFIPS 202（SHA-3）
- 鍵導出用のSP 800-108
- 乱数生成用のSP 800-90a
これらはFIDO Authenticator Allowed Cryptography Listで定義され、NIST標準を明示的に参照しています。このアーキテクチャ上に構築された発見可能な認証情報により、ユーザー名を覚える必要のないパスワードレス認証や、ブラウザの自動入力によるログイン体験の効率化が実現します。
この暗号基盤は、日常利用時のパスワードとパスキーの体感的な違いにも直結します。
ユーザー体験：パスワード vs パスキーログイン
パスワード認証は、ユーザーがサービスごとに一意の認証情報を記憶し、正確に入力し、さらにSMSコード入力やプッシュ通知承認など追加のMFA手順を完了する必要があります。この多段階プロセスは明確な摩擦を生みます。 FIDO Alliance Passkey Indexによれば、パスワードログインの成功率は平均63%で、3回に1回以上は認証情報の失念やタイプミス、MFAトークンの期限切れで失敗しています。
パスキー認証はログインを1ステップに短縮します。ユーザーは生体認証（Face ID、指紋、Windows Hello）またはデバイスPINで認証します。 FIDO Alliance World Passkey Day調査によれば、パスキーはログイン成功率93%、1回あたり平均13.6秒（パスワードは27.5秒）を達成しています。覚えるものも、入力するものも、傍受されるものもありません。生体データはデバイス内に留まり、サーバーに送信されることはありません。
組織にとって、このUX向上は運用コスト削減に直結します。FIDO Alliance Passkey Index参加企業は、パスキー導入後にサインイン関連のヘルプデスク問い合わせが81%減少したと報告しており、ITサポートの大きな定常コストを排除しています。
これらのUXメリットは、ユーザーやアプリケーションが実際にどこで動作するかに依存するため、プラットフォームやエコシステム対応状況が重要となります。
プラットフォームとエコシステムのサポート
パスキー対応は主要プラットフォームで広く利用可能となっています：
- Apple はiCloudキーチェーンを通じてiOS、iPadOS、macOS間でパスキーをエンドツーエンド暗号化で同期します。
- GoogleはAndroid 9+およびChrome上でGoogleパスワードマネージャーを通じてパスキーを管理し、同一Googleアカウントにサインインした全デバイス間で同期します。
- Microsoft はWindows 10+のWindows Helloでパスキーを統合し、EdgeやMicrosoftアカウントでサポートしています。
FIDO Allianceによれば、世界の上位100ウェブサイトの48%がパスキー認証をサポートしており、2022年比で2倍以上に増加しています。
クロスプラットフォーム認証はQRコード引き継ぎやBluetooth近接通信で実現し、ユーザーはスマートフォンに保存したパスキーでノートPCに認証できます。1PasswordやBitwardenなどのサードパーティパスワードマネージャーもパスキーの保存・同期に対応し、特定エコシステムへの依存を低減しています。FIDO AllianceのCredential Exchange Protocol（CXP）も成熟しつつあり、プロバイダー間の安全なパスキー移行を可能にし、ベンダーロックイン問題に対応しています。
ブラウザサポートも包括的です。Safari、Chrome、Edge、Firefoxはすべてパスキー認証に必要なWebAuthn APIを実装しています。これにより、ウェブアプリケーションはブラウザ固有のコードなしでパスキーをサポートできます。
この広範なプラットフォーム対応にもかかわらず、パスキーには導入前に組織が考慮すべきトレードオフも存在します。
パスキーの制限とトレードオフ
どの認証技術にも摩擦はあり、これらの制約を理解することで現実的な導入戦略を構築できます。
- エコシステム依存は依然として課題です。 同期パスキーは現時点でプラットフォーム固有の認証情報管理に紐付いています。Apple iCloudキーチェーンを利用する従業員は、Androidデバイスから直接パスキーにアクセスできません。QRコード認証やサードパーティパスワードマネージャーで回避策はあるものの、クロスエコシステムの可搬性は発展途上です。FIDO AllianceのCredential Exchange Protocolがこれを解決することを目指していますが、完全な相互運用性はまだ標準化されていません。
- 共有アカウントやサービスアカウントは複雑さを生みます。 パスキーは個々のデバイスと生体認証に紐付くため、チーム共有アカウントやサービスアカウント、複数ユーザーが同一端末で認証するキオスク端末などでは利用が困難です。多くの組織は、共有アカウントにはパスワード認証を維持し、個人ユーザーアクセスにはパスキーを展開する形で対応しています。
- パスワードなしの復旧には新たなワークフローが必要です。 ユーザーが全デバイスを紛失し、バックアップ認証器も未登録の場合、アカウント復旧は単純なパスワードリセットより複雑になります。管理者による復旧や別経路での本人確認など、十分に検証された復旧手順が必要です。
- すべてのサービスがパスキーに対応しているわけではありません。 普及が進んでいるとはいえ、多くのレガシーアプリケーション、社内ツール、サードパーティSaaS製品はWebAuthn未対応です。多くの組織は、主要なIDプロバイダーにはパスキーを導入し、移行期間中は未対応システムにパスワード認証を併用するハイブリッド運用となります。
これらの制限が、企業が実際にパスキー展開を進める際のアプローチを形作っており、データは多くの組織が複雑さを乗り越えて導入を進めていることを示しています。
企業におけるパスワード vs パスキー導入
FIDO Alliance Enterprise Deployment Surveyによると、従業員500人以上の英国・米国企業400社のうち、87%が従業員サインイン向けにパスキー認証を導入済みまたは導入中です。多くは段階的アプローチを採用し、インフラ統合を優先してから全社展開に進んでいます。パスキー導入後、パスワード利用率が26%減少しており、部分的な導入でもレガシーシステム対応を進めながらセキュリティ向上が実現できることを示しています。
自社のIDプラットフォームにはWebAuthn API対応とパスキーライフサイクル管理機能が必要です。多くの最新IDプロバイダーはWebAuthn経由でパスキー認証をサポートしています。統合はIDプロバイダー（IdP）層で行われ、ユーザーはパスキーで認証後、SAMLアサーションやOIDCトークンがフェデレーションアプリケーションに発行されます。SentinelOneのようなセキュリティプラットフォームは、 Singularity PlatformをIdPと連携させることで、認証イベント全体の可視性を維持し、パスキーベースのログインとエンドポイントアクティビティやユーザー行動分析を関連付けることができます。
モバイルデバイス管理（MDM）や統合エンドポイント管理（UEM）ポリシーも、パスキー認証器やデバイスアテステーション対応のために更新が必要です。レガシーアプリケーションの互換性が主な導入障壁となるため、全アプリケーションの棚卸しを行い、どのシステムがパスキー対応か、どこにゲートウェイやパスワード認証の継続が必要かを把握する必要があります。
ユーザーの利用率がセキュリティ成果を左右します。 Thales/FIDO Alliance State of Passkey Deployment Report（2024年）は、ユーザー教育が主要な導入課題であると指摘しています。特にパスキーの概念やデバイス間同期に関する混乱、既存習慣の変更への抵抗が記録されています。利用率向上に失敗した組織は、パスキー導入後も同じ脆弱性やコストを抱え続けるリスクがあります。
運用面の導入だけでなく、パスキー導入は企業のセキュリティ体制を規定するコンプライアンスフレームワークやゼロトラストアーキテクチャにも適合する必要があります。
コンプライアンスとゼロトラストの整合性
パスキーは、パスワードでは満たせないフィッシング耐性認証要件を満たします。NIST Special Publication 800-63Bは、AAL2でフィッシング耐性オプションの提供を明示的に要求し、AAL3ではそれを必須としています。パスワードのみの運用では、複雑さポリシーや多要素認証を重ねても、これらの要件を満たすことはできません。
連邦企業導入向けには、NIST補足ガイダンスが同期パスキーがAAL2要件を満たすことを確認しています。連邦認証鍵は、FISMA準拠を達成した同期基盤に保存される必要があります。PCI Security Standards CouncilもFAQ 1595およびFAQ 1596で、パスキーおよびFIDO2ベース認証の決済業界コンプライアンスについて明確に言及しています。
パスキーはコアな ゼロトラスト原則と整合します：
- 秘密鍵は認証器デバイスから決して離れず、認証情報の窃取やリプレイ攻撃を防止します。
- 認証は検証済みドメインに暗号学的にバインドされ、リライングパーティの検証によりフィッシングを阻止します。
- 各セッションでキャッシュ認証情報の提示ではなく、デバイス所有の暗号学的証明が求められます。
これらの特性が、ゼロトラストの「信頼せず、常に検証する」という原則を支えます。
GDPR管轄、ヘルスケア、SOC 2コンプライアンス環境下の組織にとっても、パスキーは個人データ曝露の低減とNIST AAL2/AAL3準拠のフィッシング耐性認証によりコンプライアンスを支援します。これら要件の充足が一方の側面であり、もう一方は移行中の認証インフラ全体の可視性維持です。
重要なポイント
パスワードは、攻撃者がフィッシング、クレデンシャルスタッフィング、データ侵害で盗み出す共有シークレットにより、システム全体の脆弱性を生み出します。パスキーは、秘密鍵がユーザーデバイスから決して離れない非対称 暗号技術により、これらの攻撃を排除します。
侵害の88%が盗まれた認証情報に関与し、米英の従業員500人以上の企業の87%がパスキーを導入または導入中であることから、方向性は明確です。NISTやCISAは、パスワードでは複雑さポリシーに関係なく実現できないフィッシング耐性認証を明示的に要求しています。
よくある質問
パスキーは、FIDO2/WebAuthn標準に基づいて構築されたフィッシング耐性のある認証資格情報です。非対称暗号方式を使用して、各アカウントごとに一意の公開鍵と秘密鍵のペアを生成します。秘密鍵はデバイス上に保持され、サーバーに送信されることはありません。
パスワードは、デバイスとサーバーの両方に保存される共有シークレットであり、フィッシング、クレデンシャルスタッフィング、データベース侵害のリスクがあります。パスキーは、再利用可能なシークレットを送信するのではなく、暗号学的なチャレンジレスポンスによって本人確認を行います。
パスキーは暗号学的なドメインバインディングを使用しており、認証応答が登録された特定のオリジンドメインに対してのみ有効となります。ユーザーがフィッシングサイトを訪れた場合、ブラウザのWebAuthn実装が認証応答を誤ったドメインに送信することをブロックします。
この保護はプロトコルレベルで動作し、ユーザーが不正なサイトを見分けることに依存しません。FIDOアライアンスは、同期型およびデバイスバインド型のパスキーの両方をフィッシング耐性があると正式に分類していますが、パスワードはSMS OTPやメールOTPなどと同様にフィッシングのリスクがあるカテゴリに残っています。
エンタープライズのパスキー実装では、Apple、Google、Microsoft など同じアカウントエコシステムにサインインしているデバイス間で複製される同期パスキーが使用されます。ユーザーがデバイスを紛失した場合でも、他の認証済みデバイスでパスキーに引き続きアクセスできます。組織は、すべてのデバイスへのアクセスを失った場合に備え、バックアップ認証器や管理者による復旧ワークフローを実装する必要があります。
NIST準拠のため、連邦導入環境では、NIST SP 800-63B Supplement on Syncable Authenticators で指定されているように、FISMA準拠の同期基盤に認証キーを保存する必要があります。
WebAuthnに対応していないレガシーアプリケーションは、パスキー認証を直接受け入れることができません。組織はパスキーをアイデンティティプロバイダー層で導入し、ユーザーはSAMLアサーションやOIDCトークンがフェデレーションアプリケーションに発行される前にパスキーで認証します。
これにより段階的な移行が可能となり、最新のアプリケーションはパスキー認証と直接統合し、レガシーアプリケーションはパスキーによるIdP認証後に標準のフェデレーショントークンを受け取ります。
NIST SP 800-63BはAAL2およびAAL3に対してフィッシング耐性のある認証を要求しており、パスワードは複雑さや定期変更ポリシーに関係なく要件を満たせません。CISAは重要インフラ向けのデフォルト認証として、フィッシング耐性のある方法によるパスキーを推奨しています。
PCI DSS v4.xでは、FAQ 1595および1596でパスキーに関する決済カード業界のコンプライアンス要件が示されています。連邦政府の導入では、認証鍵の保存が準拠した同期ファブリックで行われることがFISMA要件として求められます。
