はじめに

GMOコネクトの永田です。

「パスキー対応できますか？」と聞かれて、即答できませんでした😇

技術的な可否の話だと思って調べ始めたのですが、認証そのものの実装は思ったより軽かったです。重かったのは運用側でした。「最初の1つをどう渡すのか」「なくしたときどう戻すのか」が決まらないと、対応できるかどうかも判断できません。

しかも要件を詰めずに実装に入ると、後で効いてきます。たとえばドメインを決め切らないまま進めると、後から変えたときに登録済みのパスキーが全部使えなくなります。この記事は「実装の前に何を決めるべきか」を整理した記録です。

政府の対策にも「パスキーの普及促進」が施策として載り、要求元は金融から金融以外へ広がっています。同じことを聞かれる人は今後増えると思います。

先にまとめ

決めることは10個ほどあり、変更コストの大きい順に決めると手戻りが減ります。

層	決めること	後から変えると
最初に決める	①誰に使わせるか（従業員向けか一般利用者向けか） ②ドメイン設計（RP ID） ③位置づけ（一次認証か2要素目か）	登録済みパスキーが全部無効（RP ID変更）／フロー全体の作り直し
次に決める	④最初の1つをどう渡すか ⑤なくしたときどう戻すか ⑥同期を許すか端末に縛るか	運用と規制の設計やり直し。実装より重い
後から足せる	⑦オートフィル ⑧複数登録・命名 ⑨利用者向け管理画面 ⑩対応環境の線引き	追加実装で済む

一番の山場は「最初の1つの渡し方」と「なくしたときの戻し方」でした。認証そのものはブラウザが面倒を見てくれますが、この2つは自分で設計するしかありません。規制が絡むと選択肢も消えます。
従来のワンタイムコードには無かった制約が事業側に乗ります。ドメインを変えると登録済みのパスキーが全部失効するので、社名変更やサービス名変更で認証ドメインを動かせなくなります。採用を決める前に事業側と合意しておく話でした。
同じ要件でも製品ごとに詳細仕様が違います。「同期パスキーを禁止したい」「パスキーとメールのワンタイムコードを利用者に選ばせたい」「無関係な複数ドメインで1つのパスキーを使いたい」は、設定で済む／独自実装が必要／不可能に分かれました。机上で確定できないのでPoCが前提です。
パスキーの仕組み・UX・実装は書籍パスキーのすべて（技術評論社, 2025-01）が網羅しています。この記事は重複を避けて、決める順番・規制で選択肢が消える話・製品ごとの差に絞ります。

1. なぜ今聞かれるのか

金融から、金融以外へ広がっています

パスキーは「やった方がいい施策」から「求められるもの」に変わりつつあります。要求元が金融の外へ出始めています。

政府の「国民を詐欺から守るための総合対策2.0」（令和7年4月22日、犯罪対策閣僚会議決定）には「パスキーの普及促進」という項目があり、要請の対象が金融に限定されていません。

次世代認証技術の1つであるパスキーの普及のため、金融機関やＥＣ事業者等の事業を所管する省庁に対して、その導入等の促進を要請し、同要請を踏まえ、関係省庁から所管する事業者等へ各種要請を行っているところ

業種を限定しないガイドラインでも必須要件になりました。フィッシング対策協議会（業界団体で、法令ではありません）の「フィッシング対策ガイドライン2026年度版」（2026年6月1日公開）は、事業者向けの要件4を「フィッシング耐性を有する多要素認証を要求すること」とし、必須の印を付けています。パスキーがその例です。

金融の中でも証券だけの話ではありません。金融庁のガイドライン（令和6年10月4日）は銀行等・生命保険・損害保険・証券・資金決済を対象にした分野横断のものです。

金融以外でも進んでいます。メルカリはパスキーを登録したアカウントが1,090万（2025年9月時点、月間利用者の約半数）、LINEヤフーは2027年春頃までに「パスワードのみのログイン」を終了する方針を公表しています。

「自分のサービスは金融じゃないから関係ない」とは言えなくなってきています。

要求は2本立てで、パスキーは片方しか解きません

先行している証券分野では、日本証券業協会のガイドライン改正（2025年10月15日施行）で具体的な必須化まで明文化されました。読むと、2つの別々の要求が並んでいます。

	要求内容
A. 認証強度	ログイン・出金・出金先変更などの重要な操作で「フィッシングに耐性のある多要素認証（例：パスキーによる認証、PKI）」を実装し、必須化（デフォルトとして設定）する
B. 通知経路	メールやSMS内に「パスワード入力を促すページのURLやログインリンク」を記載しない（法令に基づく義務を履行するために必要な場合を除く）

この2つが独立していることが設計上効きます。パスキーを入れればAは満たせますが、Bは別問題として残ります。逆にBを守っても、認証がSMSのワンタイムパスワードのままならAは満たせません。

なぜワンタイムパスワードでは足りないのかというと、中間者型の手口に耐えられないからです。偽サイトが利用者と正規サイトの間に割り込み、入力されたコードをそのまま正規サイトへ中継してログインしてしまう手口（AiTMとも呼ばれます）が実際に使われています。先ほどの政府の対策でも、SMSの認証コードをリアルタイムに盗み取る手口の発生がパスキー普及を進める理由として挙げられていました。証券分野のガイドライン改正も、この手口による口座乗っ取りが背景にあります。

パスキーが名指しで例示されるのは、この中継が成立しないからです。パスキーは「コードのような、渡せば誰でも使える秘密」を送りません。効くのは2段階で、まず偽サイトのドメインでは、正規サイト用に登録された鍵をブラウザが使わせません（前述のRP IDの紐づけ）。そもそも中継する材料が手に入りません。仮に何らかの署名を得られたとしても、署名の対象にアクセス先のドメインが含まれるので、正規サイトへ持ち込んだ時点で検証に落ちます。中継しても使えない、というのが「フィッシング耐性がある」の中身です。

米国CISAの資料では、フィッシング耐性がある方式はFIDO/WebAuthnとPKIの2種類だけで、SMSやボイスは最後の手段（last resort）とされています。パスキーの仕組みそのものは書籍2.3（パスキーの何が優れているのか）が詳しいです。

2. 最初に決める（後から変えると作り直しになる）

2-1. 誰に使わせるのか（従業員向けか、一般利用者向けか）

これを最初に置くべきでした。ここから後続の設計が全部変わります。

	一般利用者向け（B2C）	従業員向け（B2B2E）
本人であることの根拠	申込時の本人確認、公的個人認証など	勤務先の人事による保証
最初の1つを渡す起点	既存ログイン、公的個人認証	管理者（人事）の招待
なくしたときの復旧	本人によるセルフ復旧が基本	管理者主導のリセットが自然
利用頻度	高い（アプリ導線あり）	低い（年数回、専用アプリなし）
強制できるか	離脱が怖いので段階的	業務なので比較的強制しやすい

一般利用者向けの定石をそのまま従業員向けに持ってくると噛み合いません。たとえば国内の先行事例は復旧にマイナンバーカードを使っていますが、これは申込時に本人確認をしている前提があるからです。従業員向けだと、本人であることの根拠は勤務先が持っています。

FIDO Allianceの企業向け資料では、最初のクレデンシャルの渡し方が4モデルに整理されています（管理者が一時コードを送る招待型、既存の強い認証を足場にする型、本人確認をやり直す型、対面・代理登録）。従業員向けなら招待型が素直です。

FIDO Enterprise Adoption Best Practices: Managing FIDO Credential Lifecycle

2-2. ドメイン設計（RP ID）── 変更すると全パスキーが失効します

一番手戻りが大きいのがここでした。

パスキーは登録したドメイン（RP ID）に紐づきます。RP IDに使えるのは、ログイン画面のホスト名そのものか、その親ドメイン（eTLD+1以上）のどちらかです。この範囲から外れたドメインでログイン画面を出すと、ブラウザがその鍵を使わせません。

そして鍵はRP IDごとに別物として保存されるので、RP IDを後から変えると、それ以前に登録されたパスキーは使えなくなります。

引っかかりやすいのは、1つのIdPを前段（リバースプロキシやCDN）で複数のドメインに出している構成です。この場合、次のどちらかが成り立つ必要があります。

ログイン画面を単一の正規ドメインに集約する（RP IDを1つに固定）
前段のドメイン群が共通の親ドメインを共有している（親をRP IDにする）

これは認証方式の制約ではなく、事業側の運用制約です

従来のメールやSMSのワンタイムコードには無かった性質でした。サービス名の変更や社名変更でドメインを動かすと、利用者全員に再登録してもらうしかありません。

つまりパスキーを入れると、認証を提供しているドメインを将来変えられないという制約が事業側に乗ります。コードで解決できる話ではないので、採用を決める前に事業側と合意しておく必要があります。ドメインは将来変更しない安定したものを選び、ホスト名は展開前に確定させてください。

Related Origin Requestsだけに頼るのは危険でした

無関係なドメイン（別のeTLD+1）をまたいで1つのパスキーを使いたい場合、Related Origin Requestsという仕組みがあります。RP側は https://{RP ID}/.well-known/webauthn に許可するオリジンのリストをJSONで置きます。

ただしこれはRP側だけの問題ではありませんでした。

ブラウザ側の対応も必要です。web.devの解説では対応しているのはChromeとSafariで、Firefoxは検討中の段階とされています
対応していないブラウザではフォールバックせずSecurityErrorになります。「対応ブラウザなら使える、非対応なら従来動作」ではなく、単に失敗します
Chromeでは登録できるオリジンのラベル数に上限（5）があり、超えた分は無視されます

なので「Related Origin Requestsに対応した製品を選べば複数ドメイン問題は解決する」とは言えません。利用者の端末とブラウザが揃わないと成立しないので、これを前提に設計するとサポート対象外の利用者が出ます。ドメインを1つに寄せる設計の方が堅い、という結論になりました。

仕組みの詳細は書籍の6.1（RP ID・eTLD）と8.3（複数ドメインで同じRP IDのパスキーを利用可能にする）が詳しいです。

2-3. 位置づけ（パスワードレスの一次認証か、2要素目か）

パスワードを残すかどうかで、フロー全体と復旧要件が変わります。選択肢は2つです。

一次認証として置き換える（パスワードレス）: パスワードでのログインを廃止する。なくしたときの復旧設計が必須になります
2要素目として足す: パスワードでのログインを残したまま、2つ目の要素にパスキーを使う

利用者確認つきのパスキーは1回の操作で2要素を満たせるため、FIDO Allianceはパスキーを「一次要素の置き換え」として位置づけています。

誤解しやすいところを補足すると、「パスワード＋パスキーの両方を必須にする」構成は、それ自体はフィッシングに強いです。パスワードが盗まれても、パスキーの段が偽サイトでは通らないので中間者型は成立しません。

注意が必要なのは代替の2要素目を併存させたときです。パスキーを持っていない利用者のためにSMSやTOTPも2要素目として認めると、攻撃者はパスキーを避けてそちらへ誘導できます。実効的な強度は「一番弱い経路」で決まるので、この場合はパスキーを入れてもフィッシング耐性が担保されません。移行期にありがちな構成なので、要求を満たしているつもりで満たしていない状態になりやすいところです。

規制側が求めているのは「フィッシング耐性のある多要素認証の実装および必須化」で、選択肢として用意するだけでは足りない書き方になっています。パスキーが利用者確認つきで2要素を満たすなら、パスワードを残す積極的な理由は薄い、という判断になりました。この扱いの機微は書籍2.4のコラム（パスキーは多要素認証ではない場合もあるのでは？）で整理されています。

2-4. 移行期にどう併存させるか

前項とは別の軸です。一次認証と2要素目のどちらを選んでも、切り替えた瞬間に全員がパスキーを持っている状態にはなりません。パスキーを登録済みの利用者と、まだパスワードだけの利用者が同時に存在する期間ができます。

決めることは3つでした。

決めること	選択肢
登録を促すタイミング	任意（ログイン後に案内）／必須（登録するまで進めない）
既存利用者を強制移行させるか	する（全員／未登録者のみ）／しない
いつ必須化するか	期限を決める／様子を見る

国内の先行事例は「既存ログインの後にパスキー登録を促し、しばらく任意で走らせてから期限を決めて必須化する」という順序が共通していました。一気に必須化すると離脱が出るためです。書籍3.2に登録を促すUXのケーススタディがあります。

3. 次に決める（運用と規制が絡み、実装より重い）

3-1. 最初の1つをどう渡すか

調べていて一番の発見がここでした。パスキーを「最初のクレデンシャル」として何もない状態から発行している例が、調べた範囲では見つかりませんでした。

国内の金融各社と海外の大規模サービスを当たった限りでは、いずれも既存の何か（申込時の本人確認、既存ログイン、公的個人認証、管理者発行のコード）を足場にして、そこからパスキーを「昇格」として上乗せし、段階的に必須化する順序でした。

つまり「パスキー対応」を検討すると、必ず「その前の1回目をどうするか」という問題に戻ってきます。パスキー単体はこの問いを解きません。

従業員向けの場合、その前に検討したいのがそもそも自分で渡さないという選択です。勤務先が既にSSOを持っているなら、そこへ連携してしまえば認証は企業側の資産に乗るので、受け渡しの設計自体が不要になります。連携できるかは相手次第なので当てにはできませんが、可能なら一番楽です。

自分で渡す場合、規制下で使える手段はこうなりました。

渡し方	規制との相性	実装のしやすさ
管理者が一時コードを発行して手渡す	良い（リンクを使わない）	製品によっては独自実装が必要
メールでワンタイムコードを送る（リンクなし）	許容の公算が高い（後述）	製品次第
メールでログインリンクを送る（マジックリンク）	規制下では不可	—

管理者が時間制限つきのコードを発行して本人に渡す方式は、Microsoft Entra IDのTemporary Access Passが既製の実装を持っています。公式ドキュメントでは、他のパスワードレス認証の登録（オンボーディング）と、強い認証手段をなくしたときの復旧の両方がユースケースとして挙げられています。リンクは存在せず、管理者が値を控えて本人に渡す仕組みです。

Microsoft Entra: Temporary Access Pass

「メールにコードは載せてよいのか」問題

禁止されているのは何なのかを原文で確認すると、線引きがはっきりしました。ワンタイムコードそのものは否定されていません。

分かりやすいのはフィッシング対策協議会のガイドラインです。メールにURLを載せないことを求める一方で、ワンタイムパスワードについては「送るな」ではなく書き方を指定しています。

ワンタイムパスワードが必要となるのは、サービスへのログイン、パスワードなどの重要情報の変更、振込みなどの複数の目的があることから、その目的をメッセージに含めることで、本人に心当たりがない場合、意図に反した処理が進んでいること（＝ワンタイムパスワードが窃取されようとしていること）を認識できる。

コードをメッセージで送ることが前提になっていて、そのうえで「何のためのコードか」を書けと言っています。同じガイドラインの別の要件では、メールについて「リンクURLを記載しない、もしくはテキスト形式で作成することで利用者による識別を容易にすることが望ましい」とされています。URLは載せない、コードは用途を添えて載せる、という組み合わせです。

理由を考えると納得できます。禁止の趣旨は「リンクをクリックさせて偽サイトへ誘導する」導線を断つことです。コードは、利用者が自分でブックマークから正規サイトに到達して手入力するので、その導線を作りません。実際に、証券分野でもパスキーの初回登録にメールの認証コードを使っている例があります。

過大に読まないよう、2点だけ添えておきます。

コードは通知経路の要求（B）は満たしますが、認証強度の要求（A）は満たしません。中間者型で中継され得るからです。用途は一度きりの受け渡しに限り、日常の認証はパスキーに担わせます
最終的な適用可否は自社に適用される規程の解釈になるので、法務・コンプライアンスの確認が必要です
フィッシング対策ガイドライン2026年度版（フィッシング対策協議会）

3-2. なくしたときどう戻すか ── 規制下では選択肢が減ります

書籍の8.7は復旧の選択肢を並べて「認証方法やアカウントリカバリに正解はない」と結んでいます。技術的にはその通りです。ところが規制が乗ると、選択肢の一部が落ちます。

復旧手段	規制下での扱い
メールでリセットリンクを送る	落ちる（ログインリンクの記載に当たる）
メールのワンタイムコードだけで戻す	単独では不十分（後述のNIST）
事前発行のリカバリーコード	使える（配送が不要なのが強い）
本人確認をやり直す（管理者による再確認、対面、公的個人認証など）	使える（本筋）

NIST SP 800-63B-4（2025年7月31日 Final）は、復旧の手段を4種類（保存済みリカバリーコード、発行するリカバリーコード、復旧用の連絡先、本人確認の再実行）に整理し、このいずれかを備えることを求めています（CSPs SHALL support one or more of these）。

そのうえでAAL2の復旧については、次のどれかを完了させることを要求しています（the CSP SHALL require the subscriber to complete one of the following）。

異なる手段で得た2つのリカバリーコード
1つのリカバリーコードと、アカウントに紐づいた単要素の認証器での認証を組み合わせる
本人確認の再実行

つまり単一のメールコードだけでは足りません。「パスキーをなくしたらメールでコードを送って戻す」という素朴な設計は、この時点で落ちます。

FIDO Allianceの復旧に関する推奨も同じ方向で、「復旧は最初の登録と同等以上の確からしさで行う」「弱い復旧手段の実装は推奨しない」としています。強いパスキーを入れても、復旧がSMS1本なら実効的な強度はSMS相当まで落ちる、という話です。

ここで設計の軸が見えました。復旧の本質は「秘密をどう安全に配るか」ではなく「本人確認をどうやり直すか」です。

配送を工夫する話だと思っていると、どのチャネルも一長一短で決まりません。本人確認をやり直す話だと捉えると、従業員向けなら「勤務先が本人を再確認したうえでリセットする」という答えが出ます。最初の登録が勤務先の保証で成立しているなら、復旧も同じ根拠を再現すればよいわけです。

もう1つ実務的に効くのが、そもそも復旧を必要にしないという方向です。パスキーはエコシステム単位で別のクレデンシャルになります（iCloudキーチェーンとGoogleパスワードマネージャーは別物）。片方をなくしても、もう片方が生きていれば、生存しているパスキーでログインして新しい端末のパスキーを自分で追加登録できます。複数登録を促しておくことが、高コストな復旧経路をレアケースに抑える最大の備えでした。

なお、「メールもSMSも使わず、有人対応もせず、完全に失った状態から自動で戻す」ことは原理的にできません。これは特定の製品の限界ではなく認証の本質です。どこかで本人確認をやり直す必要があります。

3-3. 同期を許すか、端末に縛るか

パスキーはクラウド同期される（複数端末で使える）ものと、端末から出せないものがあります。ここは保証レベルの話に直結します。

ここはNISTの規定がはっきりしています。SP 800-63B-4は、AAL3で使う認証器には端末から取り出せない秘密鍵（non-exportable）を要求し（SHALL have a non-exportable private key）、同期される認証器は秘密鍵を取り出せることが前提になるためAAL3では使ってはならない（SHALL NOT be used at AAL3）としています。つまり同期パスキーはAAL2までです。高い保証レベルを求められる層があるなら、端末に縛る設計と認証器の証明（Attestation）の運用が必要になります。

利便性で言えば同期は有利です。同じプラットフォームのアカウント（Apple IDやGoogleアカウント）が生きていて同期が有効なら、端末を買い替えても引き継がれるので、そもそも「なくした」状態になりにくくなります。逆にそのアカウント自体を失うと同期の恩恵も消えるので、ここは復旧設計とセットで決めることになります。

同期を禁止する方法の詳細は、書籍6章のコラム（パスキーの同期を禁止する方法はある？）と8.5・8.6に整理されています。

4. 後から足せるもの

順番の話なので、逆に「後でよいもの」も挙げておきます。

項目	内容
オートフィル（Conditional UI）	保存されたパスワードと同じ導線にパスキーを並べる。登録率・利用率への効果は大きいものの、後から追加できます
複数登録・命名	復旧の備えとしても効きます。UXの改善として後追いで足せます
利用者向け管理画面	一覧・追加・削除。運用に入ると必須になりますが、設計の順番としては後です
対応環境の線引き	どのOS・ブラウザまで対応するか。書籍4章にOS×ブラウザ×プロバイダの詳細な表があります

対応環境で1つだけ先に知っておくとよいのは、WindowsはOS標準の機能としてはパスキーの同期を持っていないという点です（passkeys.dev の対応表、2026年5月20日時点）。サードパーティの資格情報マネージャーを入れると事情が変わりますが、利用者の環境に依存します。「同期があるから端末をなくしても平気」という前提が崩れる環境がある、と押さえておくと復旧設計を詰めるときに効きます。

5. 同じパスキーでも、製品ごとに詳細仕様が違います

ここが一番情報が見つからなかったところです。WebAuthnを自分で実装する場合の情報は書籍にまとまっていますが、既存のIdP製品に任せる場合に決まるのは製品が何をどこまで持っているかです。同じ要件でも、設定で済むのか、独自実装が必要か、そもそもできないのかが製品で違いました。「パスキーに対応している」という一言では粒度が足りません。

以下は調査の性質を先に書いておきます。

Keycloak: 公式ドキュメント・ソース・issueの確認に加え、検証環境（26.6.3）で一部を実機確認
Cognito / Entra ID / Okta / Auth0 / Ping Identity: 公式ドキュメントのみの机上調査で、実機確認はしていません

この手の挙動はバージョンと環境で変わります。机上で可否を確定させるのは無理なので、要件を固めたうえで自分の環境でPoCをするのが前提という結論でした。

標準機能に入っているかどうかが違う

Keycloak 26.6.3を調べた結果です（26.4でパスキーが正式GA）。16項目ほど当たって、独自実装（SPI）が必要だったのは実質3点でした。判定が分かれたところを抜粋します。

項目	判定
一次認証／2要素目の両対応	設定で可（2系統が独立している）
他の方式との併存・利用者による選択	設定で可（Try Another Way）
リカバリーコード	設定で可（26.3でGA）
既存ユーザーへの登録強制	設定で可（必須アクション）
利用者向け管理画面・管理者操作	設定で可
メールのワンタイムコードを選択肢として出す	独自実装が必要（標準の認証手段はTOTP/HOTP・WebAuthn・リカバリーコードのみ）
同期か端末固定かを判別して強制する	独自実装が必要（フラグを見るポリシーがない）
メールリンクでのパスワードレス救済	独自実装が必要
無関係な複数ドメインでの配信	現状は不可（Related Origin Requests未対応。要望issue 39672）

「パスキーと別の方式を並べて、利用者に好きな方を選ばせたい」という要件は、標準で持っている方式どうしなら設定で並べられます（Try Another Way）。パスキーとTOTPを選ばせる構成は設定だけで組めました。

注意が要るのは並べたい方式が標準に入っていない場合です。メールのワンタイムコードは標準の認証手段に含まれていないので、選択肢に出すには自分で認証手段を作ることになります。すでに独自実装した認証手段を持っている場合も同じで、パスキーと並べる部分が自作分に依存します。「選ばせる仕組みがあるか」と「その方式を持っているか」は分けて確認しないと見積もりを外します。

逆に言えば、上の3点を要件から外せば設定だけで組めました。

併存できる製品と、排他になる製品がある

AWS Cognitoは、この「並べて選ばせる」の考え方が違いました。公式ドキュメントにはこう書かれています。

Users can either have MFA or sign in with passwordless factors

つまり利用者は「MFAを使う」か「パスワードレスでサインインする」かのどちらかで、両方は持てません。ここでいうパスワードレスの第一要素にはパスキーだけでなくメールやSMSのワンタイムコードも含まれ、一方のMFA（第2要素）はSMS・メール・TOTPから選ぶ、という別立ての構造になっています。

効いてくるのはMFAを必須にしたときです。ドキュメントによると、MFAが必須のユーザープールでは選択式サインインで使えるのが PASSWORD 系だけになり、パスワードレスの第一要素（パスキーを含む）を許可リストに追加できません。例外は、利用者確認つきパスキーを多要素として扱う設定（MULTI_FACTOR_WITH_USER_VERIFICATION）にした場合だけです。

Keycloakにはこの排他はありませんでした。「パスキーと他の方式を並べて利用者に選ばせる」という同じ要件が、製品の設計思想の違いでそのまま通らないことがあります。

Amazon Cognito: user pool MFA

「最初の1つの渡し方」は製品ごとに別物

3-1で挙げた「管理者がコードを発行して渡す」方式が、製品によって既製の機能なのか自作なのかで分かれました（Keycloak以外は公式ドキュメントベースの机上整理です）。

製品	最初の1つをリンクなしで渡せるか
Microsoft Entra ID	Temporary Access Passが該当機能として存在（時間制限つきコード、リンクなし）
Okta	既定はアクティベーションメールのリンクだが、コード入力の代替あり
Auth0	コード方式とリンク方式が別々に提供されており、コードだけで成立させられる
Ping Identity	デバイス認可のコード（user_code）を使える
Keycloak	該当機能なし。リカバリーコードは2要素目のバックアップ用途で、最初の1つには使えない。メールからWebAuthn登録を起動するissue 26145は未実装

「パスキー対応できますか？」に対して、パスキー自体は設定で入る製品でも、その手前の受け渡しで工数が出ることがあります。ここを見落とすと見積もりを外します。

まとめ

重いのは認証ロジックではなく運用側の設計でした。決めることを変更コストの大きい順に並べると手戻りが減ります。最初に決めるのは「誰に使わせるか」「ドメイン設計（RP ID）」「一次認証か2要素目か」の3つです。
ドメインを変えると登録済みのパスキーが全部失効します。これは従来のワンタイムコードには無かった、事業側に乗る運用制約でした。Related Origin Requestsという回避策はありますが、ブラウザ側の対応も必要（Firefoxは検討中で、非対応だとフォールバックせずエラー）なので、これ頼みの設計は避けた方が安全です。
山場は「最初の1つの渡し方」と「なくしたときの戻し方」でした。何もない状態からパスキーを最初のクレデンシャルとして発行している例は調べた範囲では見つからず、どこかで「その前の1回目」の設計が必要になります。
復旧は「秘密をどう配るか」ではなく、本人確認をどうやり直すかが設計軸です。規制下ではメールでリセットリンクを送る手が落ち、メールのコード1本だけで戻す手もNISTの整理では足りません。禁止されているのはリンクであってコードではない、という線引きは原文で確認できました。
「パスキーに対応している」の粒度では判断できません。同じ要件でも製品ごとに詳細仕様が違い、Keycloakは独自実装が必要な点が実質3点まで絞れた一方、Cognitoではパスキーと従来MFAが排他でした。机上調査で可否を確定させるのは無理なので、要件を固めたうえで自分の環境でPoCをする前提で見積もるのが安全です。
パスキーの仕組み・UX・実装そのものは書籍パスキーのすべてが網羅しています。この記事で触れた各項目の深掘りは、そちらが確実です。

最後に、GMOコネクトではサービス開発支援や技術支援をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。

お問合せ：https://gmo-connect.jp/contactus/