engineer.notes

try / verify / log

2026.11.06

engineer.notes
engineer.notes // programming, servers, networks, security, AI — engineer's working notes, indexed for later lookup.
検索
セキュリティ プログラミング ソフトウェア 公開日 2026.05.20 更新日 2026.10.25

パスキー (WebAuthn) 2026 年版の状況 — 普及・実装・移行戦略

パスキー(WebAuthn / FIDO2)は パスワードの後継 として急速に普及した認証技術です。2026 年時点で 主要 OS / ブラウザ / 大手サービスの対応がほぼ完了 し、「いつ自社サービスに入れるか」 が問われる段階に。普及状況、実装方法、「パスワードからの移行戦略」 を整理します。

目次（19項目）

先に要点

  • パスキー(Passkeys) は WebAuthn / FIDO2 をベースにした パスワードの後継。「公開鍵暗号で認証 → サーバはパスワードを保存しない」 仕組みのため、フィッシング / 漏洩 / 総当たり攻撃に構造的に強い。2022 年から普及が始まり、2026 年時点では 主要環境の対応がほぼ完了している。
  • 2026 年の普及状況: iOS / Android / macOS / Windows の OS レベル対応完了」 「 Chrome / Safari / Firefox / Edge の主要ブラウザ対応完了」 「 1Password / Bitwarden などのパスワードマネージャ対応完了」 「 Google / Apple / Microsoft / Amazon / GitHub / X(Twitter) など大手サービスがパスキー対応済み。
  • 実装は WebAuthn API をブラウザで呼ぶだけで、「AWS Cognito / Auth0 / Okta / Microsoft Entra ID」 などの主要なマネージド IdP が対応済み（Firebase Authentication は2026年10月時点の公式ドキュメントで標準の認証方法に含まれていない）。自前で WebAuthn を実装することは少なく、IdP の設定で有効化 が現代の標準。
  • パスキーの種類: Synced Passkey(クラウド同期)」 「 Device-bound Passkey(デバイスに紐付く) の 2 種類。「一般ユーザー向けは Synced」(iCloud Keychain / Google Password Manager で複数デバイス共有)、「エンタープライズ高セキュリティは Device-bound」(YubiKey 等のハードウェアキー)が定石。
  • 移行戦略: 既存ユーザーには段階的に提案(パスキー追加 → 任意でパスワード削除)」 「 新規ユーザーはパスキー優先」 「 リカバリ手段(メール / SMS / バックアップコード)を必ず併設。「いきなりパスワード廃止」 はユーザー離れを招くので避ける。

「パスワードはもう古い」 と何年も言われていましたが、パスキー(Passkeys) がついにそれを実現する技術として 2026 年時点で 主要環境の対応がほぼ完了しています。「Google / Apple / Microsoft / Amazon / GitHub / X」 など大手サービスが既にパスキー対応済みで、ユーザーも体験している人が増えてきました。

ざっくり言うと、パスキーは 公開鍵暗号で認証 → サーバはパスワードを保存しない 仕組みのため、OWASP Top 10（2025年版）の 「A07 認証の失敗」 に当たる問題の多くを構造的に防ぐ技術です。ただし XSS のようにページ自体が乗っ取られる脆弱性は、パスキーでは防げません。「フィッシング」 「 漏洩データベース」 「 総当たり」 に対して、「パスワードの存在を前提とした攻撃が成立しなくなる」。

この記事では、パスキーの 2026 年時点の普及状況・実装方法・移行戦略 を整理します。「パスキーの基本概念」 については パスキーと パスワード / 2FA の違い を併読してください。

2026 年の普及状況 — もう導入を遅らせる理由はない

パスキーは 2022 年に大手主導で発表されてから 4 年で OS / ブラウザ / 主要サービスがほぼ全対応に到達しました。

OS / ブラウザ

Apple のパスワード（iCloud キーチェーン）は iOS 16 以降・macOS 13 以降、Google パスワードマネージャーは Android 9 以降（Google Password Manager で同期）と各 OS の Chrome、1Password などの他社のアプリは iOS 17 以降・Android 14 以降で使えます。Windows では Windows Hello でパスキーを作ってその端末に保存でき、Windows 11 22H2（KB5030310）以降は OS でパスキーを管理できます。Windows で同期したい場合は、Microsoft Edge の Microsoft Password Manager や、Google パスワードマネージャー、他社のアプリを使います（2026年10月時点で Microsoft Learn・Google・Microsoft の公式ページを確認）。「Chrome / Safari / Firefox / Edge」 すべての主要ブラウザで動く。一般ユーザーの大半の環境で 「何の準備もなく動く」 状態。

パスワードマネージャ

「 1Password」 「 Bitwarden」 「 Dashlane」 「 LastPass」 のような主要パスワードマネージャがパスキー対応完了。「OS のキーチェーンでなくても、パスワードマネージャ経由でクラウド同期できる」 ようになり、「ベンダー横断のパスキー体験」 が成立。

大手サービスの対応

「 Google」 「 Apple アカウント」 「 Microsoft アカウント」 「 Amazon」 「 GitHub」 「 X(Twitter)」 「 Adobe」 「 Shopify」 「 PayPal」 「 eBay」 など、主要 SaaS / 消費者サービスがパスキーログイン対応済み（2026年10月時点で各社の公式ヘルプを確認。PayPal は対象のアカウントや環境に条件があります）。Google は 2023年10月10日に、個人の Google アカウントでパスキーを既定の選択肢にすると発表しました（「可能な場合はパスワードをスキップ」も既定で有効。パスワードでのログインは引き続き可能）。

エンタープライズ採用

「 Microsoft Entra ID(旧 Azure AD)」 「 Okta」 「 OneLogin」 「 Ping Identity」 などエンタープライズ IdP もパスキー標準サポート。たとえば Microsoft Entra ID は、同期するパスキーと端末固定のパスキー（セキュリティキー・Microsoft Authenticator）の両方に対応し、グループごとに許可する種類を分けたり、条件付きアクセスの認証強度でパスキーを必須にしたりできます。Okta も、パスワード管理アプリに同期されるパスキーを拒否する設定を持っています。

「もう実装環境は揃った」 状態で、「 いつ自社サービスに入れるか」 が問われる段階に来ています。

パスキーの仕組み(おさらい)

実装に入る前に、仕組みを 1 ブロックで再確認します。

公開鍵暗号ベース

「 登録時にデバイス内で鍵ペアを生成」 → 「公開鍵だけサーバに送る」 → 「認証時にサーバからチャレンジを受け、デバイス内の秘密鍵で署名 → サーバが公開鍵で検証」。パスワードはどこにも存在しない。

フィッシング耐性

「 パスキーは origin(ドメイン)に紐付く」。偽サイトに行ってもブラウザが正規ドメインのパスキーを送らない。「URL を見間違えるユーザー」 がそもそも被害に遭わない設計。

同期(Synced) vs デバイス紐付き(Device-bound)

「 Synced」 = iCloud Keychain / Google Password Manager / 1Password などで クラウド同期。「複数デバイスで使える」 利便性が高い。「Device-bound」 = 「YubiKey などハードウェア」 や 「デバイス内 Secure Enclave」 に紐付き、「 クラウドに鍵が出ない」 高セキュリティ用途。

UX

「 顔認証 / 指紋認証 / PIN」 で本人確認(これは ユーザー検証(User Verification))。「デバイスがロックされていればすぐログイン」。パスワード入力もコード入力も無い 圧倒的に楽な体験。

実装 — マネージド IdP で 1 日で動かす

「WebAuthn を自前で実装」 は非推奨。マネージド IdP に任せるのが現代の標準。

サービス パスキー対応状況 有効化の手順
AWS Cognito User Pool で対応（Lite 以外の機能プラン、選択ベースの認証フロー） サインインの「選択ベースのサインイン」に Passkey を追加し、認証方法で Passkey を設定。ログイン前にユーザー名の入力が必要
Auth0 標準サポート データベース接続でパスキーを有効にすると、Universal Login のサインアップとログインでパスキーが使える
Okta 標準サポート 管理画面の Security > Authenticators で Passkeys (FIDO2 WebAuthn) を追加
Firebase Auth 公式の認証方法の一覧にパスキーは無い（2026年10月時点） 自前の WebAuthn 実装や外部のサービスと組み合わせる
Microsoft Entra ID 対応（全エディション、Free を含む）。同期と端末固定の両方 認証方法ポリシーで Passkey (FIDO2) を有効化。条件付きアクセスの認証強度で必須にできる
自前 WebAuthn 実装 SimpleWebAuthn(Node.js)、py_webauthn(Python)、webauthn4j(Java)など ライブラリで 「Register / Authenticate のエンドポイント実装」

マネージド IdP を既に使っているなら、設定 1 つで動く のが現代のパスキー実装。自前実装はライブラリが揃っているが、「セキュリティの細部まで意識する必要」 があり、運用負荷も高い。

移行戦略 — 既存ユーザーをパスワードからパスキーへ

「いきなりパスワード廃止」 はユーザー離れを招くので NG。段階的に進める。

  1. 1
    1. パスキーをオプションとして追加

    既存ログイン(パスワード + MFA)はそのまま、"パスキーで簡単にログイン" を追加。ユーザーは任意で追加できる。

  2. 2
    2. ログイン時にパスキー登録を提案

    "次回からパスキーでログインしますか?" をログイン成功時に表示。"パスキーは安全で簡単" を短く説明。

  3. 3
    3. パスキー登録済みユーザーには優先表示

    ログイン画面で "パスキーでログイン" ボタンを最上部に。"パスワード入力" は下に隠す or リンク化。

  4. 4
    4. パスキー利用率を観測

    "何 % のユーザーがパスキーを使っているか" を継続観測。利用率が十分に上がってからパスワードの廃止を検討し、伸びないうちは案内を見直す（基準の数字は自社で決める）。

  5. 5
    5. リカバリ手段を必ず併設

    "パスキーを持つデバイスを紛失した" 場合のため、メール / SMS / バックアップコードを必ず用意。"パスキー必須化" の場合、リカバリの設計はさらに慎重に。

  6. 6
    6. パスワード機能の段階的廃止

    "パスキー利用率が高くなったユーザー" には、"パスワード削除" を提案。"完全にパスキー専用" のユーザーを増やす。

「半年〜1 年のスパン」 で段階的に進めるのが現実的です。「Google / Apple / Microsoft」 もこの段階アプローチで普及を進めてきました。

設計上の注意点

実装時に気をつけるべき点を整理します。

Resident Key(Discoverable Credential)を使う

「 ユーザーが username を入力しないでログイン」 を実現する設定。パスキーログインの UX を最大化するには必須。古い設定だと 「username 必須」 になることがあるので、IdP 設定を確認。

複数パスキー登録を許可

「 ユーザーが iPhone と Windows PC の両方にパスキーを登録できる」 ように設計。1 つのアカウントに複数の Authenticator を関連付けられる のがパスキー運用の標準。

リカバリの設計

「 パスキーを失った場合のリカバリパス」 を必ず設計。「登録済み別デバイスからの認証」 「 メール / SMS の確認コード」 「 バックアップコード」 「 ID 確認(身分証提出)」 などを組み合わせる。リカバリの抜け道がフィッシング攻撃の入口になる ので慎重に設計。

User Verification(UV)を必須に

「 顔認証 / 指紋認証 / PIN」 などのユーザー検証を必須(「userVerification: required」)に設定。UV なしのパスキーは盗まれたデバイスから誰でも使える リスクがある。「高セキュリティが要る用途では UV 必須」 は妥協しない。

エンタープライズ向け — Device-bound パスキー(ハードウェアキー)

「金融 / 医療 / 政府機関 / 大企業の管理者アカウント」 では、Synced パスキーでも不十分なケースがある。

Device-bound の特徴

「 鍵がクラウドに同期されない」 = 「特定のハードウェアでのみ使える」。クラウド事故 / アカウント乗っ取りで鍵が漏れない 最大限のセキュリティ。「YubiKey」 「 Google Titan」 「 SoloKey」 などの専用ハードウェアキーで実現。

トレードオフ

「 紛失すると完全に失効 」 「 複数デバイスで使うには複数キーを買う」 「 ユーザー教育が必要」。UX が Synced より硬い 代わりに 鍵の安全性は最高クラス。

Attestation で実装可能

「 WebAuthn の 「attestation」 オプション」 で、「どんな種類の Authenticator で登録されたか」 を IdP が検証可能。「Synced のみ拒否、ハードウェアキーのみ受付」 のような ポリシー強制 ができる。

使い分け

「 一般ユーザー = Synced パスキー(利便性重視)」 「 管理者アカウント / 高権限ロール = Device-bound(セキュリティ重視)」。ユーザー種類別にポリシーを使い分ける のが現代的設計。

移行で踏みやすい落とし穴

実装 / 運用で踏みやすいパターンを整理します。

パスワード廃止を急ぎすぎる

「 半年でパスワード廃止予定」 のような急ぎ移行は ユーザー離れ を招く。「Apple / Google でも完全廃止はせず、当面パスワード併用」 が現実的アプローチ。1 年以上の段階移行が標準。

UX の混乱

「 パスキーログイン」 「 パスワードログイン」 「 SSO ログイン」 が並ぶと、ユーザーが混乱。優先順位を明確にする(パスキー > SSO > パスワード)が定石。「残りのオプションは折りたたみ」 で UX を整理。

古いブラウザ / 環境のサポート

「 サポートの終わった古い OS やブラウザ」 「 Linux + Firefox + パスワードマネージャ未対応」 のような マイノリティ環境での挙動確認は不可欠。「サポート外環境は明示してフォールバック」 を必ず用意。

複数デバイス対応の説明不足

「 ユーザーが 「1 つのパスキーで全デバイスで使える」 と誤解」 して、別デバイスでログインできずに混乱。Synced と Device-bound の違い」 「 別デバイスでは新規パスキー登録が必要なケース を分かりやすく説明する。

パスキーへのよくある懸念 — 端末の紛失・乗り換え・アカウントの復旧

「パスキーは使わない方がよい」という意見が話題になることがあります。挙げられる懸念の多くは、端末をなくしたとき、別の会社の端末やパスワード管理アプリに乗り換えるとき、アカウントを復旧するときの3つです。どれも実際に起こりうる話なので、仕組みと備え方を公式の情報で整理します（2026年10月時点で各社のページを確認）。

懸念 公式の情報で分かること 備え方
端末をなくすと入れなくなる 同期するパスキーは、同じアカウントの別の端末で使える。Apple は、すべての端末を失っても iCloud キーチェーンの預かり（エスクロー）から復元できるとしている（iCloud のパスワード、登録した電話番号への SMS、端末のパスコードで確認） セキュリティキーのような端末固定のパスキーだけに頼らない。2つ以上の端末や方式を登録しておく
なくした端末を拾った人に使われる 使うには端末のロック解除（生体認証や PIN）が必要。Google は、端末のロックを解除できる人ならアカウントに入れると注意している 端末のロックを強くする。紛失したら、残った端末から Google アカウントなどでその端末のパスキーを削除し、ログアウトさせる
特定の会社に縛られる FIDO Alliance がパスワード管理アプリの間で認証情報を移すための仕様を公開している。Apple は iOS と macOS の 26 から、パスワードやパスキーを他のアプリとやり取りする仕組みを開発者向けに用意している 乗り換える前に、移す側と受け取る側のアプリが対応しているかを確かめる。移せないときは、新しい側で各サービスにパスキーを追加登録する
同期用のアカウントが乗っ取られると全部失う 同期の仕組みは、同期用のアカウント（Apple アカウントや Google アカウント）の守りに依存する。NIST SP 800-63B-4 は、同期できるパスキーを AAL2 までの用途に使えるとする一方、鍵を取り出せないことを求める AAL3 は満たさないとしている 同期用のアカウントを強い認証で守る。管理者アカウントのように高い保証が要る用途は、端末固定のパスキーにする
使うかどうかより、どう備えるか

Google のヘルプでは、パスキーを追加しても既存の認証方法や復元方法は変わらないとされています。つまり、パスキーを登録した後も、パスワードや復元用のメールアドレスが入口として残ります。パスキーの利点を生かすには、パスキーを2つ以上登録する、同期用のアカウントを守る、各サービスの復元方法を確かめておく、の3つをそろえることが大切です。機種変更の前に確かめることは スマホ機種変更の前に確認すべき認証まわり にまとめています。

サービスを作る側から見ると、これらの懸念は「リカバリの設計」の問題です。上の「設計上の注意点」のとおり、複数のパスキーの登録を許し、パスキーを失ったときの復旧手段を用意し、その復旧手段自体がフィッシングの入口にならないようにしておくと、利用者が安心して移行できます。

パスキーに関するよくある質問

Q. iCloud Keychain / Google Password Manager の同期は信頼できますか?

A. 一般用途では十分信頼できる。両者とも 「E2E 暗号化済みクラウド同期」 で、「Apple / Google ですら鍵を見られない」 設計。ただし Apple アカウント / Google アカウント自体が乗っ取られたら全部失う リスクがあるので、「そのアカウント自体に強力な MFA を設定」 する必要があります。また、端末そのものがマルウェアに感染していると、同期パスキーでも安全とは言えません。Palo Alto Networks の Unit 42 は 2026年8月、Windows の Chrome（Google パスワード マネージャー）で、端末上で動くマルウェアが同期パスキーを悪用できる攻撃（Pass-ta-key）を報告しました（Unit 42 の報告）。パスキーの暗号が破られたわけではなく、端末の信頼や復旧・同期の仕組みが狙われます。端末の保護（OS とブラウザの更新・マルウェア対策）と、身に覚えのない復旧や端末の再登録に気づける運用もあわせて考えます。

Q. パスキー登録時にユーザーが嫌がる場合は?

A. 必須にしない、後で登録できる動線を用意。「今は使わない」 を選べるようにし、「ログインのたびに 1 度だけ提案」 する。「提案頻度が高すぎるとうざがられる」 ので注意。任意性を保つこと で 「離脱を防ぐ」。

Q. 2FA / MFA とパスキーは併用すべき?

A. ユーザー検証(指紋 / PIN)ありのパスキーは、単体で多要素に相当する扱いにできることが多いです。「所有要素(デバイス)+ ユーザー検証」 が組み込まれているためで、たとえば AWS Cognito は設定（MULTI_FACTOR_WITH_USER_VERIFICATION）によって、ユーザー検証ありのパスキー認証を MFA として扱えます。ただし、パスワードでのログインを残している間は、パスワード側の MFA は外せません。SMS や TOTP をやめられるのは、パスワードでのログインと、それらを使う復旧手段をなくせたときです。

Q. パスキー対応していない古いブラウザのユーザーはどうする?

A. パスワード + MFA のフォールバックを残す。「パスキー対応ブラウザのユーザーには優先的にパスキー、それ以外はパスワード」 のような分岐。「サポート対象ブラウザを公式に明示」 し、「非対応環境のユーザーには案内」 する。

Q. パスキーを実装すると OWASP Top 10 対策になりますか?

A. 2025年版の A07(認証の失敗)に当たる問題に大きく効きます。「サーバーにパスワードを保存しない → パスワードの漏洩が起きない」 「 フィッシング耐性 → 偽サイト経由の認証突破が難しい」 など 構造的な防御 が成立します。ただし、パスワードや復旧手段を残せばそこが攻撃の入口になり、アクセス制御の不備や XSS のような他の項目は別に対策が要ります。

Q. 1 ユーザーに複数パスキーを登録すべき?

A. 必須に近い。「スマホと PC」 「 メインデバイスと予備デバイス」 のように 複数登録を推奨すると、「デバイス紛失時のリスク」 が大幅に下がる。「登録時に 「別デバイスもよく使う場合は今登録しておくと安心です」 と案内する」 のが UX 設計のコツ。

Q. 移行で 「パスキー利用率」 を上げるコツは?

A. ログイン成功時の 「次から簡単に」 提案」 「 UX 改善(パスキーログインを最上部に)」 「 教育コンテンツ の組み合わせ。「Google / Apple もこのアプローチで普及」 させた。「強制ではなく、便利だから自然に移行」 が広がる王道。

Q. 機種変更や別の OS への乗り換えで、パスキーは移せますか?

A. 同じ会社の端末どうしなら、同期用のアカウントでログインすれば使えます。別の会社の端末やパスワード管理アプリへは、FIDO Alliance の認証情報の移行の仕様に両方のアプリが対応していれば移せますが、対応状況はアプリによって違います。移せない場合でも、各サービスで新しい端末のパスキーを追加登録し、古いものを削除すれば乗り換えられます。

まとめ

パスキーは パスワードの構造的後継 として、2026 年時点で 主要環境の対応がほぼ完了しています。「OS / ブラウザ / パスワードマネージャ / マネージド IdP」 が揃った今、「いつ自社サービスに入れるか」 が問われる段階です。

「いきなりパスワード廃止」 ではなく、「オプション追加 → 優先提案 → 段階的廃止」 の 1 年以上のスパンで進めるのが現実的。「Cognito / Auth0 / Okta のような IdP を使っていれば、設定 1 つでパスキー対応」 できる現代では、「実装コストは非常に低い」 です。「認証回りの抜本改善」 として、「パスキー対応を 2026 年中に進める」 のは多くのサービスで合理的な判断です。

参考リンク

あとで見返すならここで保存

読み終わったあとに残しておきたい記事は、お気に入りからまとめて辿れます。