FIDO2&多要素認証(MFA)実装ガイド|仕組み・設計・運用の徹底解説

認証のセキュリティ強化が喫緊の課題となる中、パスワードレス認証やFIDO2への移行を検討する企業が増えています。しかし「導入したものの運用が回らない」「セキュリティ担当の負荷が急増した」という声も少なくありません。
・リモートサービスへのパスワードレス認証とは？種類も解説！

本ガイドでは、FIDO2/WebAuthnの仕組みから、MFA方式の選定基準、IdP/SSOとの連携設計、運用の落とし穴まで、実務で使える形で解説します。

導入検討中の情報システム部門、セキュリティ担当者、運用設計者の方々に向けて、技術的な正確性と実運用の現実をご紹介します。

FIDO/FIDO2の基礎(WebAuthnとCTAPの関係)

FIDO(Fast IDentity Online)は、パスワードに依存しない認証の標準規格です。
FIDO Allianceが策定し、現在主流となっているのがFIDO2です。
FIDO2は、以下2つの仕様で構成されます

• WebAuthn(Web Authentication API): ブラウザとWebアプリケーション間の認証プロトコル
• CTAP(Client to Authenticator Protocol): クライアント(ブラウザ/OS)と認証器(セキュリティキー、生体センサーなど)間の通信プロトコル

この2層構造により、ユーザーはセキュリティキーや指紋認証などの認証器を使い、フィッシング耐性の高い認証を実現できます。

公開鍵暗号・認証器・チャレンジ応答の流れ

FIDO2認証の核心は公開鍵暗号方式にあります。従来のパスワード認証では「秘密(パスワード)」をサーバーに送信・保管していましたが、FIDO2では秘密鍵は認証器内に閉じ込められ、外部に漏れることがありません。

登録(Registration)フロー

1. ユーザーがWebサイトで登録を開始
2. サーバーがチャレンジ(ランダム値)を生成
3. 認証器が鍵ペア(秘密鍵・公開鍵)を生成し、秘密鍵を安全に保存
4. 公開鍵とチャレンジへの署名をサーバーに送信
5. サーバーが公開鍵を登録

認証(Authentication)フロー

1. ユーザーがログインを開始
2. サーバーが新たなチャレンジを生成
3. 認証器が秘密鍵でチャレンジに署名
4. サーバーが保存済みの公開鍵で署名を検証

このチャレンジ応答方式により、リプレイ攻撃やフィッシング攻撃を防ぎます。認証器はRP ID（通常は登録サイトの有効なドメイン）を検証するため、フィッシングサイトなど正しいRP IDと一致しない環境では認証が成立しません。

FIDO2の公開鍵・秘密鍵管理とセキュリティチップ(TPM等)による保護については、ホワイトペーパーでも詳しく解説しています。

MFA方式の比較(TOTP/SMS/プッシュ/パスキー/FIDO2)

多要素認証には複数の方式があり、セキュリティ強度・ユーザビリティ・コストが異なります。

方式	フィッシング耐性	ユーザビリティ	導入コスト	備考
SMS/音声通話	×(低)	△(遅延あり)	低	SIMスワップ攻撃のリスク、通信不良で認証不可
TOTP(Google Authenticator等)	×(低)	○(オフライン可)	低	共有秘密が漏洩すると脆弱、時刻同期が必要
プッシュ通知	△(中)	◎(ワンタップ)	中	MFA疲労攻撃のリスク、通信環境依存
FIDO2セキュリティキー	◎(高)	○(物理的操作)	中〜高	紛失リスク、配布・管理コスト
パスキー(WebAuthn)	◎(高)	◎(生体認証)	中	同一エコシステム内（Apple/Google/Microsoft）での同期は実用段階。ただし、異なるエコシステム間の相互運用は依然として課題

フィッシング耐性とユーザビリティのトレードオフ

最もセキュアなFIDO2セキュリティキーは物理的なデバイス操作が必要で、ユーザーにとっては「もう1つ持ち歩くもの」になります。一方、パスキー（プラットフォーム認証器）は生体認証でシームレスですが、同一エコシステム内同期に依存するため、紛失・乗り換え時はローミング認証器やリカバリーコードとの二本立て設計が不可欠です。
プッシュ通知は利便性が高い反面、攻撃者が繰り返し送信してユーザーの承認疲れを誘う「MFA疲労攻撃」のリスクがあります。そのため、プッシュを採用する場合は「番号マッチング」「頻度制限」「地理・端末異常時の追加要素要求」を最低限の前提として組み込みます。
実務では、リスクベース認証との組み合わせが推奨されます。通常の環境からのアクセスでは生体認証、異常な場所やデバイスからはFIDO2キーを要求、といった段階的な設計が効果的です。

INPなどCWVに配慮したUI設計ポイント

ユーザー体験(UX)の観点では、Core Web Vitals(CWV)の一指標であるINP(Interaction to Next Paint)が重要です。認証フローが遅延すると、ユーザーは離脱します。
UI設計は以下のポイントを押さえましょう。

• 認証モーダルの遅延ロード:初期ページロードを軽量化し、認証が必要になった時点でWebAuthn APIを呼び出す
• フォールバック表示: 認証器が応答するまでスピナーやプログレス表示で待機感を軽減
• タイムアウト設定: WebAuthn APIのタイムアウトはUXを優先して60秒前後に短め設定を推奨。仕様上の推奨デフォルトは5分（推奨範囲は5～10分）だが、実務では“待ち時間の体感”を抑えるため短縮するケースが一般的。
• エラーハンドリング: 認証器が見つからない場合の代替フロー(SMS/TOTPへのフォールバック)を明示

特にモバイル環境では、認証器(指紋センサーなど)へのアクセスが遅い場合があります。INPを200ms以下に抑えるには、認証開始ボタンのイベントリスナーを軽量化し、WebAuthn呼び出しを非同期で処理する設計が必須です。

企業導入の設計(IdP/SSO・デバイス前提・鍵/認証器保護)

企業でFIDO2/MFAを導入する際は、IdP(Identity Provider)やSSO(Single Sign-On)との統合設計が鍵となります。
代表的なIdP

• Microsoft Entra ID(旧Azure AD)
• Okta
• Google Workspace
• OneLogin
• WinMagic MagicEndpoint IdP

多くのIdPがFIDO2/WebAuthnをネイティブサポートしており、設定画面から有効化できます。
ただし、以下の設計判断が必要です。

• デバイス登録の前提: 企業支給デバイスのみか、BYODも許可するか？
• 認証器の種類: プラットフォーム認証器(Windows Hello、Touch ID、WinMagic MagicEndpointなど)か、ローミング認証器(YubiKeyなど)か、両方を許可するか？
• 段階的ロールアウト: IT／情報システム部門→権限の強い部門（財務・人事）→全社の順で展開し、問い合わせパターンを先に学習してからスケールさせる。

秘密鍵・認証器保護とバックアップ設計(TPM/ローミング)

FIDO2の秘密鍵は認証器内に保存されますが、ハードウェア保護のレベルは認証器により異なります。

• TPM(Trusted Platform Module): PCのセキュアチップに鍵を保存。Windows Hello、WinMagic MagicEndpointなどが利用
• セキュアエレメント: スマートフォンやセキュリティキー内の専用チップ
• ソフトウェア保護: OS標準の鍵ストア(Android Keystore、iOS Keychainなど)

バックアップ設計の考慮点

• デバイス紛失: 予備の認証器(セキュリティキー)を配布しておく、またはリカバリーコードを発行
• 認証器の同期: AppleはiCloud Keychain、GoogleはGoogle Password Manager、MicrosoftはEdge＋Microsoft Password Managerでパスキーの同期を提供。いずれも同一エコシステム内の同期が前提であり、クロス・エコシステムの乗り換えや混在運用には代替策（ローミング認証器など）の併用が必要。
• ローミング認証器の推奨: 特定デバイスに依存しない認証を実現するにはYubiKeyなどのUSBセキュリティキーが有効

企業ではBCP(事業継続計画)の観点から、認証器紛失時の迅速なリカバリー手順を整備することが重要です。

運用の落とし穴(担当への負荷、紛失/退職、例外端末など)

FIDO2/MFA導入後に顕在化しやすい運用課題を以下に挙げます。

担当への負荷の急増

• 「認証器を忘れた/紛失した」問い合わせが集中
• 一時的なバイパス手順(管理者による認証無効化)の乱用
• 対策: セルフサービスポータルでのリカバリーコード発行、事前教育の徹底

紛失・デバイス交換・退職時の流れ

• 認証器を紛失した従業員のアカウントから、古い公開鍵を削除
• 退職者の認証器が社外に持ち出されても、サーバー側で公開鍵を無効化すれば認証不可
• 対策: IdPと連携した自動プロビジョニング・デプロビジョニング(SCIM)の導入

例外端末・共有端末

• 受付端末や工場の共有PCでは個人の認証器を使いづらい
• 対策: 共有アカウント用の専用認証器、またはリスクベース認証で緩和

ゲスト・来訪者の扱い

• 外部パートナーに認証器を配布するコストとリスク
• 対策: 一時的なOTPやSMS認証へのフォールバック、または来訪者用の専用ネットワーク

MFA疲労攻撃への対策マッピング(プッシュ抑制、FIDO2化)

MFA疲労攻撃(MFA Fatigue Attack)は、攻撃者が繰り返しプッシュ通知を送信し、ユーザーが誤って承認してしまうことを狙います。

対策効果と導入難易度

対策	効果	導入難易度
プッシュ通知の頻度制限	中	低
番号マッチング(Number Matching)	高	中
FIDO2への移行	非常に高	高
異常検知とアラート	中	中

番号マッチングは、プッシュ通知に数字を表示し、ログイン画面で同じ数字を入力させる方式です。Microsoft Entra IDでは既定で有効化されており、ユーザーが画面を見ずに承認するリスク（MFA疲労）を大幅に低減します。
最も強力な対策はFIDO2への全面移行ですが、段階的に進める場合は、まず重要システム(財務、人事など)からFIDO2を適用し、一般業務ではプッシュ+番号マッチングを併用する設計が現実的です。
MFA疲労攻撃の詳細なパターンと対策は、こちらの記事で具体例を交えて解説しています。

ゼロトラスト/SSOとの連携(SAML/OIDC/SCIMの基本)

FIDO2/MFAは、ゼロトラストアーキテクチャの「認証・認可」層を支える基盤技術です。
主要なプロトコルは以下です。

• SAML 2.0(Security Assertion Markup Language): エンタープライズSSOの標準。IdPが認証後、SAMLアサーション(トークン)をSP(Service Provider)に渡す
• OIDC(OpenID Connect): OAuthの上に構築された認証プロトコル。Webサービスやモバイルアプリでよく利用
• SCIM(System for Cross-domain Identity Management): ユーザー・グループ情報の自動プロビジョニング。IdPとSP間でユーザー属性を同期

統合の流れ

1. IdP(Microsoft Entra ID、Okta、MagicEndpointなど)でFIDO2/MFAを有効化
2. 各SPにSAML/OIDC連携を設定
3. SCIMで自動プロビジョニングを構成(ユーザー追加・削除を自動同期)
4. 条件付きアクセス(Conditional Access)でリスクベース認証を実装

これにより、ユーザーは一度IdPで認証すれば、複数のSaaSアプリケーションに自動ログイン(SSO)できます。

MagicEndpoint活用例

MagicEndpointは、PC起動前のプリブート認証とWindowsログオン、MagicEndpoint IdPへのログオン、クラウドサービスへのアクセスをシームレスに連携できるエンドポイント向けセキュリティ製品です。
また、Microsoft Entra ID（旧Azure AD）などのIdPとSSOを組み合わせることでMicrosoft 365などのクラウドサービスへのアクセスをシームレスに統合できる構成も可能です。
MagicEndpointのデモ構成例については、デモ動画でもご紹介しています。
さらに、SecureDocと組み合わせることで、BitLockerなどの暗号化管理や回復キー管理を一元化し、運用負荷の削減や紛失・盗難時のリスク対策を強化できます。

※連携内容は組織の認証設計・ポリシー・管理ツール構成によります。
MagicEndpointの仕様や製品の特長はこちら
 SecureDocの仕様や製品の特長はこちら

導入チェックリスト(配備・教育・運用・BCP)

FIDO2/MFA導入をスムーズに進めるためのチェックリストです。

事前準備フェーズ

対象システム・ユーザー範囲の特定(全社 or パイロット部門)
• IdP/SSOの選定・契約(Microsoft Entra ID、Okta、WinMagic Magic Endpoint IdP等)
• 認証器の選定(プラットフォーム認証器 or ローミング認証器)
• セキュリティキーの調達・配布計画(数量、予備の確保)
• ネットワーク・ファイアウォール要件の確認(WebAuthn通信の許可)

設計・設定フェーズ

• IdPでFIDO2/WebAuthnを有効化
• 条件付きアクセスポリシーの設計(リスクベース認証)
• フォールバック認証の設定(SMS/TOTP/リカバリーコード)
• SAML/OIDC/SCIM連携の構成(各SaaSアプリ)
• セキュリティ担当向けリカバリー手順の整備

教育・展開フェーズ

ユーザー向けトレーニング資料の作成(動画・マニュアル)
• パイロット部門での先行展開・フィードバック収集
• セキュリティ担当向けトレーニング(よくある問い合わせ対応)
• 全社展開スケジュールの策定・告知
• 認証器の配布・登録サポート(対面 or リモート)

運用・監視フェーズ

• 認証ログの監視・異常検知(失敗回数、異常なロケーション)
• 定期的な認証器の棚卸し(未使用・紛失の確認)
• ヘルプデスク問い合わせの分析・改善
• 四半期ごとのセキュリティレビュー(新たな脅威への対応)

BCP(事業継続計画)

認証器紛失時のリカバリー手順の文書化
• 災害時のバックアップ認証手段(リカバリーコード、予備キー)
• 管理者アカウントの緊急アクセス手順
• 定期的なBCP訓練(年1回以上)

FAQ(よくある質問)

Q1. 認証器(セキュリティキー)を紛失した場合はどうすればよいですか?
A: 速やかにセキュリティ担当に連絡し、紛失した認証器の無効化を依頼してください。多くの組織では、リカバリーコードや予備の認証器を事前に配布しています。管理者は、IdP管理画面から該当ユーザーの公開鍵を削除し、新しい認証器を再登録します。
BCP観点から、2つ以上の認証器(例: YubiKey + Windows Hello)を登録しておくことを推奨します。

Q2. 共有端末(受付端末、工場のPCなど)ではどう運用すればよいですか?
A: 共有端末では個人の認証器を使わせるのは現実的ではありません。以下の対策があります:
• 専用の共有認証器: 端末に紐付けられたセキュリティキーを設置し、担当者間で共有
• リスクベース認証の緩和: 共有端末は特定ネットワークからのみアクセス可能とし、MFA要件を緩和
• セッションタイムアウトの短縮: 自動ログアウトまでの時間を短く設定

Q3. 来訪者やゲストにもFIDO2認証を求めるべきですか?
A: 一般的には不要です。来訪者には以下の対応が推奨されます:
• ゲストWi-Fi(業務ネットワークと分離)
• 一時的なアカウント + SMS/TOTP認証
• ポータル画面からのセルフ登録・認証
重要なシステムへのアクセスが必要な外部パートナーには、事前に認証器を配布するか、VPN + MFAの組み合わせを検討します。

Q4. シンクライアント環境やVDIでもFIDO2は使えますか?
A: 使えますが、設計上の考慮が必要です:
• USB/NFCのリダイレクト: VDIプロトコル(Citrix、VMware Horizon等)がUSBリダイレクトに対応しているか確認
• ブラウザの対応: VDI内のブラウザがWebAuthn APIをサポートしているか
• プラットフォーム認証器: VDI内ではなく、クライアント端末(シンクライアント本体)の認証器を使う設計も可能
Citrix、VMware Horizon（Omnissa）、Azure Virtual DesktopなどはWebAuthn／FIDO2リダイレクトを公式サポートしています。構成により「USBデバイスのリダイレクト」と「WebAuthnリダイレクト」の使い分けや制限が異なるため、製品ごとのドキュメントに従って設計してください。利用形態によっては仮想セッション内のみ有効となる構成もあるため、要件（セキュリティ強度／操作性／周辺機器対応）に合わせて方式を選定します。

Q5. FIDO2への移行は一斉に行うべきですか、それとも段階的に?
A: 段階的な移行を強く推奨します。理由は以下の通りです:
• ユーザー教育・サポート体制の負荷を分散
• 予期せぬ問題(デバイス互換性、業務フロー)を早期発見
• 対応パターンを蓄積
推奨ステップ:
1. パイロット部門(IT部門など)で先行導入
2. フィードバックを反映し、手順を改善
3. 部門ごとに段階的にロールアウト
4. 最終的に全社展開

まとめ:実務で使えるFIDO2/MFA実装の勘所

FIDO2と多要素認証は、パスワードレスの未来を拓く技術であると同時に、運用設計が成否を分ける領域です。

成功のポイント

• 技術だけでなく運用を設計: 紛失時フロー、手順、BCPなど
• 段階的な展開: パイロット→フィードバック→全社展開
• ユーザー教育の徹底: 利便性とセキュリティの両面をわかりやすく伝える
• エコシステム間の相互運用を前提に：同一エコシステム内同期のパスキーとローミング認証器を併用し、BCP とライフサイクル（紛失・交換・退職）に強い構成にする。

本ガイドで紹介した設計原則・チェックリスト・FAQを参考に、自社に適したFIDO2/MFA導入を進めてください。
WinMagicへのお問い合わせはこちらから

参考資料
W3C WebAuthn Level 3 仕様（最新版のリファレンス）
Web 認証 API (WebAuthn) のパスキーを有効にする【Microsoft Learn】
CISA Secure by Demand Guide | FIDO Alliance
iCloudキーチェーンを設定する – Apple サポート