MFAの義務化とパスキーへの移行：ベストプラクティス

1. はじめに：義務化されたMFAの新たな現実#

多要素認証（MFA）は、積極的なユーザーのためのセキュリティ機能から、世界中の組織にとって交渉の余地のない義務化された現実へと決定的にシフトしました。この変革は選択によるものではなく、執拗なクレデンシャルベースのサイバー攻撃と高まる規制圧力によってもたらされた必要性によるものです。金融サービスから公共部門に至るまで、各業界は現在、MFAをコンプライアンスのベースラインとするフレームワークの下で運営されています。MFAが提供されるのではなく強制されるこの新時代は、初期の技術的実装をはるかに超える連鎖的な複雑な課題をもたらします。

すべてのユーザーがMFAを使用しなければならない場合、すべての組織が答えなければならない新たな一連の重要な問題が浮上します。この記事では、これらの課題を深く掘り下げ、前進するための明確な道筋を提供します。以下について取り上げます。

1. 大規模なMFAの強制に伴う、隠れた運用コストとユーザーエクスペリエンスの落とし穴とは何か？

2. 選択肢が与えられた場合、ユーザーは実際にどのMFA手法を採用し、これがどのようなセキュリティリスクを生み出すか？

3. 義務化された環境において、アカウントのリカバリはどのようにして新たな主要な課題となるのか、またそれを解決する際のトレードオフは何か？

4. なぜパスキーは単なる別の選択肢ではなく、MFAの義務化によって引き起こされる問題そのものに対する戦略的な解決策なのか？

5. 義務化されたレガシーMFAから、パスキーの優れたセキュリティとユーザーエクスペリエンスにうまく移行するための、実践的かつ段階的な青写真とは何か？

この分析は、単一要素認証から義務化されたMFA（そして義務化されたパスキー）への移行を成功させるための、明確で実行可能な青写真を提供します。

2. セキュリティのシフト：義務化されたMFAのコンテキストを理解する#

強制の課題を探求する前に、認証のランドスケープと、なぜ義務化がそれを根本的に変えるのかについて明確な理解を確立することが重要です。専門用語自体が混乱の元になることもありますが、その区別はセキュリティ戦略や製品戦略にとって極めて重要です。

2.1 簡単なおさらい：SFA、2SV、および真のMFA#

認証の進化は、その最も基本的な形態に内在する弱点に対する直接的な対応です。

• 単一要素認証（SFA）： おなじみのユーザー名とパスワードの組み合わせです。これは、ユーザーが知っていることである単一の「知識」要素に依存しています。フィッシング、クレデンシャルスタッフィング、ブルートフォース攻撃に対する脆弱性が、より強力な方法を推進する主な要因です。

• 2段階認証（2SV）： 多くの場合、MFAと同義で使用されますが、2SVは異なり、より弱いプロセスです。2つの検証ステップが必要ですが、同じカテゴリの2つの要素を使用する場合があります。一般的な例は、パスワードの後に続く秘密の質問であり、どちらも「知識」要素です。SFAよりは優れていますが、真の多要素セキュリティの基準を満たしていません。

• 多要素認証（MFA）： セキュリティのゴールドスタンダードであるMFAは、少なくとも2つの異なるカテゴリの認証要素からの検証を必要とします。主な3つのカテゴリは以下の通りです。

  • 知識： ユーザーが知っていること（例：パスワード、PIN）。

  • 所持： ユーザーが持っているもの（例：コードを受信する携帯電話、ハードウェアセキュリティキー）。

  • 生得性： ユーザー自身であること（例：指紋、顔認識）。

2.2 なぜ義務化がすべてを変えるのか#

オプションから義務化されたMFAへの移行は、パラダイムシフトです。オプションのシステムでは、最もセキュリティ意識の高いユーザーによる段階的な導入が可能であり、真のフリクションのポイントが隠されます。義務化は、テクノロジーに精通したユーザーからテクノロジーを敬遠するユーザーまで、ユーザーベース全体を新しいシステムに同時に強制し、ユーザーエクスペリエンスとサポート構造のすべての欠陥を露呈させます。

このシフトは、世界的な規制のカタリストによって加速されています。最も注目すべきは、ヨーロッパの第2次決済サービス指令（PSD2）と強力な顧客認証（SCA）の要件であり、これはほとんどのオンライン取引にMFAを義務付けることで、ヨーロッパの決済の状況を根本的に再構築しました。金融機関にオープンAPIとより強力なセキュリティの採用を強制することにより、PSD2は強制的な認証における大規模な現実のケーススタディを提供します。

SCAの主な目的は、電子決済に2つの独立した認証要素を要求することで不正行為を減らすことでした。しかし、初期の展開では大きなフリクションが生じ、一部のヨーロッパの加盟店は、ユーザーの混乱とカゴ落ちにより、取引のほぼ40%を失いました。時間の経過とともにエコシステムは適応し、欧州中央銀行の2024年8月の報告書では、SCA認証取引の不正率が大幅に低下したことが確認されました。これは長期的なセキュリティ上の利点を示していますが、同時にセキュリティとユーザーエクスペリエンスのバランスをとるという重要なニーズも浮き彫りにしています。

同様の規制の勢いが世界的に高まっています。オーストラリアでは、金融セクターはオーストラリア健全性規制庁のCPS 234フレームワークの下で運営されており、金融機関のセキュリティ基準を定めています。2025年初頭のクレデンシャルスタッフィング攻撃の波に続き、APRAはすべてのスーパーアニュエーションファンドの理事会に書簡を送り、リスクの高い活動に対してMFAまたは同等の保護を実装することを明確に期待しました。規制当局は、オーストラリアの金融セクターにおけるサイバーインシデントの約20%がクレデンシャルスタッフィング攻撃であり、MFAが重要な管理手段であることを指摘しました。これとは別に、オーストラリアの電気通信セクターは、オーストラリア通信メディア庁の2022年顧客本人確認決定に基づく、すべての高リスクの顧客取引に対してMFAの義務化に直面しています。この規則は、注目のSIMスワッピング詐欺事件を受けて、SIMの交換、パスワードのリセット、およびサービスの追加にMFAを使用することを通信事業者に義務付けています。

これらの義務化は初期にはフリクションを生み出しますが、同時に非自発的な大衆教育の環境をも生み出します。数百万人のユーザーが銀行から指紋やコードで取引を承認することを強制されると、彼らは第2要素の概念に慣れ親しむようになります。規制によって推進されるこの標準化は、逆説的に他の組織の道を平坦にします。会話は「MFAとは何か、なぜそれが必要なのか？」から「これが、あなたがすでに知っているセキュリティステップを実行する新しい簡単な方法です」へと発展する可能性があります。これにより、パスキーのような優れたエクスペリエンスを導入するための完璧な基盤が構築されます。

これらの規制の詳細とパスキーとの関係について詳しく知りたい場合は、以下のリソースをご覧ください。

• PSD2およびSCA要件の分析

• SCA要件がパスキーにとって意味すること

• PSD2パスキー：フィッシング耐性のあるPSD2準拠のMFA

• PSD3 / PSRがパスキーに与える影響

• PSD3 / PSRにおける委任認証とパスキー

2.3 セキュリティ侵害が行動を強制する場合：インシデント後の義務化#

規制のフレームワークがプロアクティブなMFAの導入を促進する一方で、セキュリティインシデントはしばしば最も緊急で目に見える義務化を引き起こします。組織が侵害を受けた場合、義務化されたMFAへの道は、コンプライアンス計画の問題ではなく、即時の危機対応となります。

オーストラリアのスーパーアニュエーションセクターは、2025年3月にこれを如実に経験しました。高度なクレデンシャルスタッフィングキャンペーンにおいて、サイバー犯罪者は外部の侵害から盗まれたユーザー名とパスワードの組み合わせを使用して、退職金口座を組織的に攻撃しました。ロイターとABCニュースの報道によると、300万人以上のメンバーを抱える国内最大のファンドであるAustralianSuperは、攻撃者が最大600のメンバーアカウントにアクセスし、攻撃が検出される前に4人のメンバーの残高から50万豪ドルを不正に引き出したことを確認しました。このインシデントは複数のファンドに広がり、Rest Superは約20,000のアカウントで不審なアクティビティを検出し、Insignia Financialは約100のアカウントで攻撃の試みを報告しました。

攻撃ベクトルは典型的なクレデンシャルスタッフィングであり、関連のないデータ侵害から収集されたクレデンシャルを使用した自動化されたログイン試行でした。ABCニュースのインタビューを受けたセキュリティの専門家は、この攻撃を「洗練されていない」と特徴づけ、その成功はMFAの欠如に完全に起因していると指摘しました。対照的に、他の主要なファンドであるHostPlusは、メンバーアカウントにMFAをすでに実装していたため、同じキャンペーンによる金銭的損失はゼロであったと報告しました。この現実世界の比較は、MFAの保護価値の明白な証拠を提供しました。

侵害の前に、AustralianSuperの顧客はセキュリティオプションとしてMFAを明示的に要求していましたが、利用できないと知らされていました。インシデント後、ファンドは影響を受けたアカウントを直ちにロックし、MFAの展開を加速させました。その後のAPRAの書簡は、すべてのスーパーアニュエーションの理事長に対して、MFAの実装は将来の検討事項ではなく、緊急の義務であるという規制当局の期待を明確にしました。

侵害後の義務化は、組織のクレデンシャルを侵害するフィッシングキャンペーンからも生じます。2020年3月、州政府のサービスポータルであるService NSWは、736 GBのデータが公開されるフィッシング攻撃を受け、約103,000人の顧客の個人情報が侵害されました。調査官は、スタッフのメールアカウントにMFAがないことが、侵害の深刻さの主な要因であると特定しました。これに対応して、Service NSWはすべての外部メールシステムにMFAを実装し、2021年8月までに500万豪ドルのセキュリティ投資に支えられ、外部に面したシステムの95%でMFAを有効にしました。2022年の個別のOptusの電気通信データ侵害の後、Service NSWはさらに取り組みを拡大し、2026年までにすべてのMyServiceNSWアカウント所有者にMFAを試験導入してから義務化しました。

これらのインシデントは重要なパターンを示しています。侵害は、プロアクティブなコンプライアンスに典型的な段階的な計画サイクルを迂回する、政治的および運用上の圧力を生み出します。質問は「MFAを義務付けるべきか？」から「どれだけ早く展開できるか？」へと変わります。この圧縮されたタイムラインは、この記事の後半で説明するユーザーエクスペリエンスと運用上の課題を悪化させることが多く、MFA方式の選択と展開の設計がさらに重要な結果をもたらします。

3. 隠れた複雑さ：MFAの義務化が実際に意味するもの#

ユーザーベース全体にMFAを適用すると、初期の計画段階では過小評価されがちな、現実のさまざまな課題が浮き彫りになります。これらの問題は、ユーザーエクスペリエンス、セキュリティ体制、運用コストに影響を与えます。

3.1 オンボーディングのハードル：大規模な登録#

登録が義務付けられている場合、ユーザーエクスペリエンスの低下は単なる煩わしさではなく、ビジネス運営の直接的な障害になります。組織は通常、2つの戦略から選択します。次のログイン時にMFAのセットアップを要求する強制登録と、時間の経過とともにユーザーにプロンプトを表示する段階的登録です。強制登録はコンプライアンスをより早く達成しますが、プロセスがシームレスでない場合、ユーザーの不満や離脱が高まるリスクがあります。成功の鍵は、複数の認証方法の提供、非常に明確な手順の提供、すべてのユーザーのアクセシビリティの確保など、UXのベストプラクティスを遵守することにあります。たとえば、認証アプリ用のQRコードと一緒にテキストベースのシークレットキーを提供します。

3.2 リカバリの悪夢：新たなNo.1サポートの問題#

アカウントでMFAが有効になると、第2の要素を失うことは完全にロックアウトされることを意味します。義務化された世界では、これはセキュリティ意識の高い少数のユーザーにとって孤立したインシデントではありません。それはユーザーベース全体と、ユーザーにサービスを提供するサポートチームにとって、広範で重大な課題になります。これにより、アカウントのリカバリは単一の最大の課題になります。

金銭的な賭けは高いです。ヘルプデスク主導のパスワードまたはMFAのリセット1回につき、企業には平均70ドルの費用がかかる可能性があります。何十万人ものユーザーを抱える組織の場合、少数のユーザーでもリカバリが必要になると、運用コストと生産性の損失で数百万ドルに達する可能性があります。

組織は、セキュリティ、コスト、利便性の間の難しいトレードオフを強いられます。

• ヘルプデスク主導のリカバリ： サポートエージェントは、ビデオ通話やその他の手段を通じてユーザーの身元を確認できます。これは安全で人間が検証するプロセスですが、法外に費用がかかり、拡張が遅いため、ほとんどのビジネスにとって持続不可能です。

• メール/SMSベースのリカバリ： これは、低コストでユーザーに馴染みがあるため、最も一般的な方法です。しかし、重大なセキュリティの脆弱性でもあります。攻撃者がすでにユーザーのメールアカウント（他の攻撃の一般的な前兆）を侵害している場合、リカバリコードを簡単に傍受してMFAを完全にバイパスできます。この方法は、義務化が提供することを意図したセキュリティ上の利点を事実上無効にします。

• 事前登録されたバックアップコード： ユーザーには、登録時に1回限りのバックアップコードのセットが渡されます。メールのリカバリよりも安全ですが、このアプローチは初期設定にフリクションを追加します。さらに、ユーザーはこれらのコードを安全に保存できなかったり、紛失したりすることがよくあり、最終的には同じロックアウトの問題に戻ることになります。

• 自撮り写真IDの検証： この高い保証の方法では、ユーザーがライブの自撮り写真と政府発行の身分証明書（運転免許証やパスポートなど）の写真を撮る必要があります。その後、AIを活用したシステムが顔を身分証明書と照合し、本人確認を行います。オンボーディング時に本人確認が行われる銀行や金融サービスでは一般的ですが、一部のユーザーにとってはプライバシーの懸念が生じ、物理的な身分証明書を手元に用意する必要があります。

• デジタルクレデンシャルとウォレット： 新たな先進的なオプションとして、デジタルウォレットに保存された検証可能なデジタルクレデンシャルの使用があります。ユーザーは、信頼できる発行者（政府や銀行など）からのクレデンシャルを提示することで、サービス固有のリカバリフローを経由せずに本人確認を行うことができます。この方法はまだ初期段階にありますが、よりポータブルでユーザー主導の本人確認の未来を示しています。

3.3 デバイスのライフサイクルの問題：新しい電話、アクセスの喪失#

あらゆるMFAシステムにおける頻繁かつ重大な障害ポイントは、デバイスのライフサイクルです。ユーザーが新しい電話を取得したとき、認証方法の継続性が最も重要です。

• SMS： 電話番号は新しいSIMカードを介して新しいデバイスに転送できるため、この方法は比較的ポータブルです。しかし、このプロセス自体がSIMスワッピング攻撃で悪用される攻撃ベクトルであり、詐欺師が携帯電話会社を説得して被害者の番号を彼らが管理するSIMに移植させます。

• 認証アプリ（TOTP）： これはユーザーフリクションの大きな原因です。ユーザーが認証アプリ内でクラウドバックアップ機能を積極的に有効にしていない限り（この機能は普遍的ではなく、常に使用されているわけではありません）、コードを生成するシークレットキーは古いデバイスとともに失われます。これにより、ユーザーは保護していたすべてのサービスに対して、完全で、しばしば苦痛を伴うアカウントのリカバリプロセスを強いられます。

• プッシュ通知： TOTPアプリと同様に、プッシュベースのMFAは登録されたデバイスへの特定のアプリのインストールに関連付けられています。新しい電話には新しい登録が必要であり、同じリカバリの課題を引き起こします。

3.4 ユーザー選好のパラドックス：最も抵抗の少ない道#

組織がMFAを義務付け、さまざまな方法の選択肢を提供すると、予測可能なパターンが浮かび上がります。95%以上のユーザーが、最も馴染みがあり、最も簡単だと認識されているものに惹かれます。これは多くの場合、SMSベースのワンタイムパスコード（OTP）です。この行動はパラドックスを生み出します。CISOはセキュリティを向上させるためにMFAを義務付けることができます。しかし、多くのユーザーがSMSのようなフィッシング可能な方法に依存し続ける場合、組織は洗練された攻撃に対する防御を実質的に向上させることなく、100%のコンプライアンスを達成することになります。

2025年3月のオーストラリアのスーパーアニュエーションの侵害は、この問題の明白で現実世界の証拠を提供しました。そのインシデントでは、MFAがまったくないことが決定的な脆弱性でした。しかし、より広い教訓は「MFAがあるかないか」の二元論を超えて、展開されたMFAの質に及びます。SMSベースのMFAのみを主要な、または唯一のオプションとして提供する組織は、フィッシング、ソーシャルエンジニアリング、およびSIMスワッピング攻撃に対して脆弱なままです。オーストラリアのケースの攻撃者は、弱いクレデンシャルを悪用しました。もしそれらのアカウントがSMS OTP「のみ」によって「保護」されていたとしたら、侵害されたメールアカウントにアクセスできる攻撃者は、パスワードリセットのフローを傍受し、SIMスワップを引き起こして、その要素もバイパスする可能性がありました。

これを認識し、Microsoftのようなプラットフォームは「システム優先MFA」を導入し、ユーザーにSMSや音声通話よりも認証アプリのようなより安全なオプションを積極的に推奨しています。これは重要な教訓を浮き彫りにしています。単にMFAを義務付けるだけでは不十分です。MFAの種類は非常に重要であり、組織はユーザーを弱くフィッシング可能な要素から積極的に遠ざけなければなりません。

3.5 運用への損害：包囲されたヘルプデスク#

MFAの義務化の決定は、運用リソースに直接的かつ測定可能な影響を与えます。登録の問題、認証システムの紛失、リカバリ要求に関連するヘルプデスクのチケットの急増を必然的に引き起こします。ガートナーの調査によると、ITサポートへの電話の30〜50%がすでにパスワード関連の問題によるものです。義務化されたMFAは、特に煩雑なリカバリフローと組み合わされた場合、この負担を大幅に悪化させます。これは、CTOとプロジェクトマネージャーが予測しなければならない直接的なコストに相当します。さらに、ヘルプデスク自体がソーシャルエンジニアリング攻撃の主な標的になり、攻撃者はイライラしてロックアウトされたユーザーになりすまして、サポートエージェントを騙して代わりにMFA要素をリセットさせます。

4. 大規模なMFA義務化からの重要な教訓#

義務化されたMFAの大規模な現実世界での実装を調べることで、何が機能し、何が重大なフリクションを生み出すかについての貴重な教訓が得られます。ヨーロッパのPSD2のようなプロアクティブな規制の展開と、オーストラリアの金融セクターにおけるインシデント後のリアクティブな義務化の両方からの経験を分析することで、いくつかの普遍的な真理を抽出できます。

• 初期のフリクションは避けられないが、管理可能である： ヨーロッパのSCAの展開は、セキュリティのためであっても、ユーザーの行動に大きな変更を強制すると、最初はコンバージョン率に悪影響を及ぼすことを実証しました。しかし、プロセスを洗練させ、ユーザーを慣れさせることで、これらの悪影響を時間の経過とともに軽減できることも示しました。鍵となるのは、このフリクションを予測し、最初から可能な限り合理的でユーザーフレンドリーなフローを設計することです。

• ユーザーの選択肢は諸刃の剣である： 選択肢が与えられた場合、ユーザーは一貫して最も抵抗の少ない道を選択します。これは多くの場合、SMSのように馴染みがあるが安全性の低いMFA方法を選択することを意味します。これは「コンプライアンスの劇場化」の状態につながり、組織は義務化の文面は満たしていても、その精神は満たしておらず、フィッシングに対して脆弱なままです。2025年3月のオーストラリアのスーパーアニュエーション攻撃は、この原則を逆から実証しました。MFAがない組織は大きな損失を被りましたが、（HostPlusのように）基本的なMFAでさえ導入している組織は金銭の窃盗を防ぎました。しかし、教訓はさらに広がります。SMSのみに基づく弱いMFAの実装は、SIMスワップやソーシャルエンジニアリングを悪用できる決意のある攻撃者に対して脆弱なままです。成功する戦略は、より強力でフィッシング耐性のあるオプションに向けてユーザーを積極的に導くものでなければなりません。

• リカバリがアキレス腱になる： 義務化された世界では、アカウントのリカバリはエッジケースから主要な運用の負担および重大なセキュリティの脆弱性へと変貌します。リカバリにメールやSMSに依存することはセキュリティモデル全体を弱体化させますが、ヘルプデスク主導のリカバリは財政的に持続不可能です。堅牢で安全、かつユーザーフレンドリーなリカバリプロセスは後付けではなく、あらゆる成功する義務化のコア要件です。

• 侵害後の義務化はタイムラインを圧縮し、リスクを増幅させる： 計画されたコンプライアンスのイニシアチブではなく、セキュリティインシデントによって義務化が引き起こされた場合、実装のタイムラインは劇的に圧縮されます。オーストラリアのスーパーアニュエーションセクターは、侵害から数週間以内に「顧客がMFAを要求している」状態から「規制当局が即時の展開を期待している」状態へと移行しました。この加速されたタイムラインは、ユーザーテスト、段階的な展開、反復的な洗練のための余地を減らし、テクノロジーの選択とユーザーエクスペリエンスの設計をさらに重要なものにします。侵害の前にプロアクティブにMFAを実装する組織には慎重な計画を立てる余裕がありますが、インシデントの後に対応を余儀なくされる組織にはありません。

• 段階的な展開はリスクを劇的に低減する： ユーザーベース全体への「ビッグバン」の展開を試みることは、高リスクの戦略です。大規模なエンタープライズ展開で実証されているより慎重なアプローチは、最初に小規模で重要でないユーザーグループで新しいシステムを試験導入することです。これにより、プロジェクトチームは本格的な展開の前に、制御された環境でバグを特定して解決し、ユーザーエクスペリエンスを洗練させ、フィードバックを収集することができます。

• 統合されたアイデンティティプラットフォームは強力なイネーブラーである： 既存の統合されたIdentity and Access Management（IAM）またはシングルサインオン（SSO）プラットフォームを持つ組織は、スムーズな展開に向けてはるかに良い立場にあります。中央のアイデンティティシステムにより、数百または数千のアプリケーションに新しい認証ポリシーを迅速かつ一貫して適用でき、プロジェクトの複雑さとコストを大幅に削減できます。

5. 避けられない次のステップ：パスキーが義務化の問題を解決する理由#

FIDO AllianceのWebAuthn標準に基づいて構築されたパスキーは、レガシーMFAに対する単なる漸進的な改善ではありません。公開鍵暗号に基づくそれらの基盤となるアーキテクチャは、MFAの義務化によって引き起こされる最も苦痛で永続的な問題を解決するために専用に構築されています。

• リカバリの悪夢の解決： 義務化されたMFAの単一の最大の課題は、アカウントのリカバリです。パスキーはこれに真正面から取り組みます。パスキーは暗号化クレデンシャルであり、（AppleのiCloudキーチェーンやGoogleパスワードマネージャーのような）プラットフォームエコシステムを通じてユーザーのデバイス間で同期できます。ユーザーが電話を紛失した場合でも、パスキーはラップトップやタブレットで引き続き利用できます。これにより、ロックアウトの頻度が劇的に低下し、メールのような安全でないリカバリチャネルや費用のかかるヘルプデスクの介入への依存が軽減されます。

• デバイスのライフサイクルの問題の解決： パスキーは同期されるため、新しいデバイスを取得するエクスペリエンスは、高フリクションのポイントからシームレスな移行へと変化します。ユーザーが新しい電話でGoogleまたはAppleのアカウントにサインインすると、パスキーは自動的に復元され、すぐに使用できます。これにより、従来のデバイスにバインドされた認証アプリで必要だった、苦痛を伴うアプリごとの再登録プロセスが不要になります。

• ユーザー選好のパラドックスの解決： パスキーは、古くからのセキュリティと利便性のトレードオフを解決します。利用可能な最も安全な認証方法である、フィッシング耐性のある公開鍵暗号は、ユーザーにとっても最も速く、最も簡単です。1回の生体認証ジェスチャーまたはデバイスPINだけで済みます。最も強力なオプションが同時に最も便利なオプションであるため、ユーザーがより弱く安全性の低いオプションを選択するインセンティブはありません。

• フィッシングの脆弱性の解決： パスキーは設計上フィッシング耐性があります。登録時に作成された暗号化キーペアは、Webサイトまたはアプリの特定のオリジン（例：corbado.com）にバインドされます。ブラウザとオペレーティングシステムはオリジンの不一致を認識して認証の実行を拒否するため、ユーザーがそっくりなフィッシングサイト（例：corbado.scam.com）でパスキーを使用するように騙されることはありません。これは、（パスワードやOTPなどの）共有シークレットに基づく方法では提供できない、根本的なセキュリティの保証を提供します。

• MFA疲労の解決： Face IDのスキャンや指紋のタッチなど、単一のシンプルなユーザーアクションは、デバイス上の暗号化キーの所持（「あなたが持っているもの」）と生体認証による生得性（「あなた自身であること」）の両方を同時に証明します。これはユーザーにとっては単一の手間のかからないステップのように感じられますが、暗号学的には多要素認証の要件を満たしています。これにより、組織はレガシーMFAに関連する余分な手順や認知負荷を追加することなく、厳格なコンプライアンス基準を満たすことができます。

6. 戦略的転換：義務化されたパスキーに移行するための青写真#

レガシーMFAからパスキーファーストの戦略への移行には、テクノロジー、ユーザーエクスペリエンス、ビジネス目標に対処する、慎重なマルチステージのアプローチが必要です。

6.1 ステップ 1：デバイスの準備状況を監査する#

パスキーを義務付ける前に、ユーザーベースがパスキーを採用するための技術的能力を理解する必要があります。これは、展開の実現可能性とタイムラインを測定するための重要な最初のステップです。

• デバイス環境の分析： 既存のWeb分析ツールを使用して、ユーザーが好むオペレーティングシステム（iOS、Android、Windowsのバージョン）とブラウザに関するデータを収集します。

• パスキー準備状況ツールの展開： より正確なデータを得るには、State of Passkeys のような軽量なデータリソースが役立ちます。これにより、（Face ID、Touch ID、Windows Helloなどの）プラットフォーム認証器と、パスキーの自動入力を可能にするConditional UIなどの重要なUXの強化をサポートするデバイスを持つユーザーの割合に関する洞察が得られます。このデータは、現実的な採用モデルを構築するために不可欠です。

6.2 ステップ 2：ハイブリッドなフォールバックアーキテクチャを設計する#

パスキーへの移行は段階的であり、瞬時ではありません。成功する戦略には、パスキーを主要な推奨される方法として促進しつつ、互換性のないデバイスを使用しているユーザーやまだ登録していないユーザーに対して安全なフォールバックを提供するハイブリッドシステムが必要です。

• 統合パターンの選択：

  • 識別子ファースト： ユーザーはメールアドレスまたはユーザー名を入力します。システムはその識別子にパスキーが登録されているかどうかを確認し、登録されていればパスキーのログインフローを開始します。そうでない場合は、パスワードまたは別の安全な方法にシームレスにフォールバックします。このアプローチは最高のユーザーエクスペリエンスを提供し、一般に採用率を高めます。

  • 専用のパスキーボタン： 従来のログインフォームの横に「パスキーでサインイン」ボタンを配置します。これは実装が簡単ですが、新しい方法を選択する責任をユーザーに負わせるため、使用率が低下する可能性があります。

• フォールバックが安全であることを確認する： フォールバックメカニズムがセキュリティ目標を弱体化させてはなりません。SMS OTPなどの安全でない方法へのフォールバックは避けてください。より強力な代替手段は、特定のセッションの所持要素として機能する、検証済みのメールアドレスに送信される時間制限付きのワンタイムコードまたはマジックリンクを使用することです。

6.3 ステップ 3：ユーザー中心の教育と展開計画を作成する#

スムーズな展開には効果的なコミュニケーションが不可欠です。目標は、パスキーを単なるセキュリティ上の煩わしさとしてではなく、ユーザーエクスペリエンスの大幅なアップグレードとして位置付けることです。

• メリット主導のメッセージング： ユーザーのメリットに焦点を当てた、明確でシンプルな言葉を使用します。「より速く、より安全にサインイン」「忘れてしまうパスワードにさようなら」「あなたの指紋があなたの鍵になります」などです。公式のFIDOパスキーアイコンを一貫して使用して認識を構築します。

• 段階的な展開戦略：

  1. 「プル」による採用から始める： 最初は、ユーザーのアカウント設定ページ内にオプションとしてパスキーの作成を提供します。これにより、アーリーアダプターやテクノロジーに精通したユーザーは、他のユーザーのフローを妨げることなくオプトインできます。

  2. 「プッシュ」による採用に移行する： システムが安定したら、ユーザーが古いパスワードで正常にサインインした直後に、パスキーを作成するよう積極的に促し始めます。これにより、ユーザーがすでに「認証の考え方」になっているときにユーザーを捉えることができます。

  3. オンボーディングに統合する： 最後に、すべての新規ユーザーのサインアップで、パスキーの作成を主要な推奨オプションにします。

6.4 ステップ 4：監視、測定、反復#

パスキーへの投資を検証し、エクスペリエンスを継続的に最適化するには、データ主導のアプローチが不可欠です。すべてのチームは、それぞれの役割に関連する指標を追跡する必要があります。

• 採用とエンゲージメントの指標：

  • パスキー作成率： パスキーを作成した適格なユーザーの割合。

  • パスキー使用率： パスキーを使用して実行された総ログイン数の割合。

  • 最初のアクションまでの時間： 新規ユーザーがパスキーを採用した後、重要なアクションを実行するまでの速さ。

• ビジネスと運用の指標：

  • パスワードリセットチケットの削減： ヘルプデスクコストの削減の直接的な尺度。

  • SMS OTPコストの削減： レガシー要素の排除による目に見えるコスト削減。

  • ログイン成功率： パスキーのログイン成功率とパスワード/MFAのログインの比較。

  • アカウント乗っ取りインシデントの減少： セキュリティの有効性の究極の尺度。

以下の表は、認証方法を比較し、パスキーソリューションを一般的なビジネスのペインポイントに直接マッピングした簡潔な要約を提供します。

パスキーが義務化されたMFAのペインポイントにどのようにソリューションを提供するか

結論：コンプライアンスを競争上の優位性に変える#

義務化された多要素認証の時代は今後も続きます。クレデンシャルベースの攻撃を防御するという重大な必要性から生まれましたが、これらの義務化は意図せずして新たな課題の状況を生み出しました。

MFAの強制が、SMS料金の直接的なコストから、登録やデバイスの変更に苦労するユーザーからのヘルプデスクチケットの急増まで、重大な運用の負担をもたらすことを見てきました。選択肢が与えられた場合、ユーザーはSMSのような馴染みがあるがフィッシング可能な方法に引き寄せられ、紙の上ではコンプライアンスを達成しますが、組織は現実世界の攻撃にさらされたままになることがわかりました。最も重要なことは、義務化された世界では、アカウントのリカバリが単一の最大の障害ポイントとなり、不適切に処理された場合にはユーザーの計り知れない不満の元となり、セキュリティ上の大きな穴となることを確認しました。

レガシーなMFA方法ではこれらの問題を解決できません。しかし、パスキーなら解決できます。パスキーが決定的な答えであり、リカバリ、ユーザーのフリクション、セキュリティという相互に関連する問題を直接解決することを実証しました。同期の性質により、ほとんどのロックアウトシナリオが排除され、生体認証の使いやすさにより、より弱いオプションを選択するインセンティブがなくなり、暗号化の設計によりフィッシングの影響を受けません。最後に、準備状況の監査から成功の測定まで、あらゆる組織がこの戦略的転換を行うための実践的な道筋を提供する、明確な4段階の青写真を示しました。

このシフトをコンプライアンス上の頭痛の種としてのみ見なすことは、それがもたらす戦略的な機会を逃すことになります。ヨーロッパの銀行における強力な顧客認証のパイオニアたちは、初期の困難にもかかわらず、最終的には業界全体のユーザーの期待を形成しました。今日、パスキーのパイオニアたちは同じ機会を持っています。この移行を受け入れることで、組織はセキュリティの義務化を重荷から、強力で持続的な競争上の優位性へと変革することができます。義務化からモメンタムへと移行を計画する時は今です。

Corbadoについて

Corbadoは、大規模なconsumer認証を運用するCIAMチームのためのAuthentication Intelligence Platformです。IDPのログや一般的なanalyticsツールでは見えないものを可視化します。どのデバイス、OSバージョン、ブラウザ、credential managerがpasskeyに対応しているか、なぜ登録がログインにつながらないのか、WebAuthnフローのどこで失敗するか、OSやブラウザのアップデートがいつ静かにログインを壊すか — Okta、Auth0、Ping、Cognito、あるいは自社IDPを置き換えることなく、すべてを把握できます。2つのプロダクト：Corbado Observeは passkeyとその他あらゆるログイン方式のobservabilityを提供します。Corbado Connectは analytics内蔵のmanaged passkeyを追加します（既存のIDPと併用）。VicRoadsはCorbadoで500万人超のユーザーにpasskeyを提供しています（passkey有効化率+80%）。 Passkeyエキスパートに相談する →

よくある質問#

全ユーザーにMFAが義務付けられた場合、アカウントのリカバリはどのように機能しますか？#

MFAの義務化により、アカウントのリカバリは運用の主な課題となり、4つの主要なオプションがあります。ヘルプデスク主導の検証（安全だが高価）、メールまたはSMSのリカバリ（安価だがメールが侵害された場合に悪用可能）、事前登録されたバックアップコード（ユーザーが紛失しがち）、および政府発行の身分証明書を必要とする自撮りIDの検証です。各オプションには、セキュリティ、コスト、スケーラビリティの間のトレードオフが含まれます。

SMSベースのMFAを義務付けても、依然として組織がフィッシングに対して脆弱なままなのはなぜですか？#

SMS OTPは、リアルタイムのフィッシング、SIMスワッピング、侵害されたメールアカウントを通じたリカバリのバイパスに対して脆弱です。100%のMFA登録であっても、SMSに依存することは、組織が義務化の文面は満たしていても精神は満たしていないことを意味します。Microsoftの「システム優先MFA」の導入は、ユーザーにSMSではなく認証アプリを積極的に推奨することで、この問題を認識しています。

2025年のオーストラリアのスーパーアニュエーションのクレデンシャルスタッフィング攻撃では何が起こり、MFAについて何を証明しましたか？#

2025年3月、攻撃者は盗まれたクレデンシャルを使用して最大600のAustralianSuperのアカウントにアクセスし、4人のメンバーの残高から50万豪ドルを不正に引き出しました。すでにMFAを実装していたHostPlusは、同じキャンペーンによる金銭的損失はゼロであったと報告しました。その後、APRAはすべてのスーパーアニュエーションの理事長に書簡を送り、MFAの実装は将来の検討事項ではなく緊急の規制上の義務であるとしました。

パスキーはTOTP認証アプリと比べて、新しいデバイスの登録をどのように処理しますか？#

パスキーは、AppleのiCloudキーチェーンやGoogleパスワードマネージャーなどのプラットフォームエコシステムを通じて同期し、サービスごとの再登録なしに新しいデバイスで自動的に復元されます。TOTP認証アプリは、事前にクラウドバックアップを手動で有効にしていない限り、デバイスを交換するとすべてのシークレットキーを失うため、デバイスの交換は義務化されたMFAの下でヘルプデスクチケットとアカウントのロックアウトの主な要因となります。

ユーザーをレガシーMFAからパスキーに移行するために推奨される段階的な展開戦略は何ですか？#

3段階の導入アプローチにより、展開のリスクが軽減されます。まず、既存のフローを中断することなくアーリーアダプターを獲得するために、アカウント設定内のオプトインとしてパスキーの作成を提供します。次に、パスワードでのログインが成功した直後、ユーザーがすでに認証の考え方になっているときに、パスキーを作成するように促します。第3に、新規ユーザーのオンボーディング中にパスキーの作成を主要な推奨事項にします。