パスキーとFIDO2の比較：安全でパスワードレスな認証のための詳細ガイド

By Mirko Peters · 2026-04-26 · Updated 2026-09-13

フィッシング耐性のあるパスワードレス認証に向けて、パスキーとFIDO2セキュリティキーを比較します。WebAuthn、Microsoft Entra ID、リカバリー、エンタープライズへの展開について解説します。

Automatically translated with AI from the original post. Read the English original

Titelbild: Passkeys vs FIDO2: In-Depth Comparison for Secure, Passwordless Authentication

パスキーとFIDO2のどちらを選ぶかは、利用シナリオ、セキュリティ要件、Microsoft 365環境に基づいて、明確かつ実践的に判断する必要があります。まず達成したい目的を明確にし、最新のMicrosoftのガイダンスを確認したうえで、代表的なユーザーでテストし、広く適用する前に責任者を文書化してください。

実践的なパスキーとFIDO2のチェックリスト

ビジネスシナリオと責任者を定義します。
代表的なパイロット導入で設計を検証します。
セキュリティ、アクセス、サポートへの影響を確認します。

最新の製品ガイダンスについては、Microsoft Learnを参照してください。

最終レビュー日：2026年7月。

パスワードの煩わしさやリスクを抱えることなく、デジタルアカウントを保護することが新たな標準になりつつあります。ご自身や組織で最新の認証方式を検討しているなら、FIDO2やパスキーの話を耳にしない日はないでしょう。これら2つの用語はよく使われていますが、実際に何を意味し、実環境でのセキュリティ、使いやすさ、展開の必要性という点でどう違うのか、特にMicrosoft中心の環境ではどうなのか、整理しておく価値があります。

本記事では、基本を整理します。FIDO2とパスキーの仕組み、両者の違い、そしてデバイスやクラウドサービス全体のログインの仕方をなぜ変えつつあるのかを解説します。脅威モデル、コンプライアンス、ユーザーエクスペリエンスについての実践的なポイントに加え、定着するパスワードレス認証を設定する際の細かな注意点もご紹介します。Microsoft 365を管理している方、社内のITを担当している方、あるいは悪意のある攻撃者に簡単に狙われないアカウントを求めている方にとって、役立つ内容になっています。

FIDO2とパスキーとは

FIDO2は、FIDO AllianceとWorld Wide Web Consortium（W3C）が策定した、パスワードレス認証のためのオープンな標準です。その中核的な目的は、公開鍵暗号を用いて、パスワードなしで安全にログインできるようにすることです。FIDO2の中心には2つの主要なプロトコルがあります。Webサイトやアプリケーション向けのWebAuthnと、スマートフォンやハードウェアキーなどの認証器との通信を行うCTAPです。

パスキーは、FIDO2標準をユーザーにとって使いやすくした実装です。平たく言えば、「パスキー」は基本的にFIDO2のクレデンシャルであり、iCloudキーチェーン（Apple）、Googleパスワードマネージャー、Microsoftの資格情報マネージャーなど、デバイスのOSによって管理されるものです。パスキーは単独のパスワードに代わるもので、デバイスのロックを解除したり、Face ID、Touch ID、Windows Helloなどの生体認証を使ったりしてログインできます。

ここで重要なのは、すべてのパスキーは内部でFIDO2に依存しているものの、すべてのFIDO2クレデンシャルが「パスキー」として提供されているわけではない、という点です。パスキーには、デバイス間の同期や簡単なリカバリーといった利便性が追加されていることが一般的ですが、使われている暗号の仕組み（公開鍵と秘密鍵）は同じです。従来のパスワードは覚えておく秘密ですが、FIDO2とパスキーでは秘密（秘密鍵）をデバイス内に保持し、サーバーとは証明情報のみをやり取りし、鍵そのものは決して送信しません。

まとめると、FIDO2認証は標準化された仕組みを提供し、パスキーはその仕組みをお手元のスマートフォンやノートPC、クラウドに届けます。どちらも、パスワードレスでフィッシング耐性のあるログインを実現することを目指しています。

パスワードの廃止とフィッシング耐性の実現

FIDO2とパスキーの主な目的は、サインインを簡単にすることだけではありません（それも大きな利点ではありますが）。フィッシング、パスワードの使い回し、総当たり攻撃による推測に弱いことで知られるパスワードを、ついに廃止することにあります。FIDO2とパスキーでは、認証は公開鍵暗号に基づいています。攻撃者がフィッシングしたり盗んだりできるパスワードは、送信も保存もされません。

ログインは、指紋、顔認証、デバイスPINなどによってデバイスのロックを解除することから始まります。その後デバイスは、秘密鍵を保有していることを暗号学的に証明します。この証明は、正しいサーバー（リライングパーティーと呼ばれます）に対してのみ有効であり、鍵が通信上に送信されることはありません。たとえハッカーが偽のWebサイトであなたを騙したとしても、その鍵は本物のサイトのオリジンに紐付けられているため、機能しません。

このアプローチにより、類似サイトで認証情報を盗み取る従来型のフィッシング攻撃は、ほぼ役に立たなくなります。奪って別のサービスで再利用できるパスワードが存在せず、ログインのたびに新しいチャレンジが発行されるため、攻撃者は取得した認証情報を再送することもできません。漏えいしたパスワードを使って大量ログインを試みる認証情報スタッフィングも、パスキーであれば最初から成立しません。

組織がこの方式に移行しているのは、技術的なセキュリティの理由だけではありません。コンプライアンスやビジネス上の理由もあります。FIDO2とパスキーを導入し、特に Microsoft Defender for Office 365 や Microsoft Purview for data governance のようなツールと組み合わせることで、ユーザーの負担を増やさずに認証情報を狙う攻撃の一群を丸ごと遮断できます。

FIDO2認証の仕組みを詳しく見る

従来型のログインと比べてFIDO2がなぜはるかに安全なのかを理解するには、ブラックボックスの中身を見ておくと役立ちます。FIDO2の核心は、アカウントを解除する秘密情報を一切明かさずに、公開鍵暗号を使ってサービスに対して本人であることを証明する点にあります。

FIDO2のログインを設定する(またはパスキーを登録する)と、デバイスは一意の鍵ペア、つまり公開鍵と秘密鍵を生成します。公開鍵はログイン先のサービスに渡されますが、秘密鍵がデバイスの外に出ることはありません。サインインのたびに、サーバーはデバイスに対して秘密鍵を持っていることの証明を求めます。通常はランダムな値に署名させ、その結果を、サーバーが保持している公開鍵で検証します。

これらはすべて、厳密に管理されたストレージとユーザー検証に基づいています。つまり秘密鍵は安全なエンクレーブに保管され、デバイスのロックを解除するか生体認証を行ったときにのみアクセスできます。これが、Microsoft Windows、Apple macOS/iOS、Androidのように、ハードウェアに裏付けられたセキュリティを強制できるシステムで、FIDO2とパスキーの採用が急速に広がっている大きな理由です。

登録と認証のフローの詳細、そして認証情報がどのように保護され、デバイスに紐付けられるかについては、以降のセクションで取り上げます。

FIDO2の登録と認証のフロー解説

登録: FIDO2を使ってサービスに初めてサインアップするとき、デバイスは新しい暗号鍵ペアを作成します。公開鍵はサービス(リライングパーティー)に送信され、秘密鍵はデバイスに残ります。
アテステーション: デバイスは、認証器として正当であることを示すアテステーション証明書を提示することで、その認証情報がセキュアなハードウェア内で生成されたことをサービスに証明できます。
認証: ログインの際、サービスは一意のチャレンジを送信します。デバイスは、PIN、指紋認証などによるユーザー検証を経たうえで、このチャレンジを秘密鍵で署名します。
サーバー側の検証: 署名されたチャレンジはサーバーに返され、保存済みの公開鍵を使って検証されます。検証に成功すればサインイン完了です。秘密情報は一切やり取りされず、フィッシングの対象になる情報もありません。

パスキーのセキュアな保管とデバイスへの紐付け

ハードウェアに裏付けられたセキュリティ: パスキーとFIDO2認証情報は、多くの場合、Trusted Platform Module(TPM)、Secure Enclave(Apple)、Titan M チップ(Google)などの専用のセキュアハードウェア内に保存されます。これにより鍵がデバイスの他の部分から分離され、攻撃がはるかに困難になります。
生体認証またはPIN認証: パスキーを使うには、通常は生体認証またはデバイスのPINでロックを解除する必要があります。生体情報そのものがハードウェアの外に出たり、オンラインサービスに送信されたりすることはないため、本人を特定する情報は非公開のまま保たれます。
デバイスへの紐付け: 暗号鍵ペアは、オンラインのアカウントだけでなく、物理的なデバイスに紐付けられています。そのため攻撃者がアクセスするには、デバイスを侵害したうえでローカルの保護を突破しなければなりません。
認証情報のエクスポートと同期の保護: iCloud キーチェーンやGoogle パスワードマネージャーのように、複数のデバイス間でパスキーを同期するプラットフォームでは、認証情報はエンドツーエンドで暗号化されます。適切な認証を経た自分のデバイスだけが、パスキーを読み取り、使用できます。
ライフサイクルのセキュリティ: デバイスを初期化または廃棄する際に、資格情報を安全に消去できます。組織はMicrosoft Entra ID と条件付きアクセスポリシーなどのソリューションを使って、資格情報の使用を制御し、侵害への対応を行うことで、アクセスのガバナンスを強制できます。

同期されるパスキーとソフトウェアバインド型ソリューションの比較

パスキーはすべて同じではありません。パスワードレス認証を設定すると、資格情報の管理方法の違いにすぐ気づくはずです。主な違いは、クラウドを介して複数のデバイス間で同期されるか、単一のデバイスに固定されるかという点です。こうしたアーキテクチャ上の選択は、使いやすさとリスクの両面に実際の影響を及ぼします。

iCloud キーチェーン (Apple デバイス) や Google パスワードマネージャー (Android) から利用できる同期パスキーは、電話、タブレット、コンピューターの間でサインイン情報を利用できるため、多くの場合とても便利です。一方で、クラウドプロバイダーが侵害された場合や同期が中断された場合に露出するおそれがあるなど、セキュリティと信頼性のトレードオフも伴います。

一方、ソフトウェアバインド型パスキーは完全に単一のデバイス上に存在します。新しいデバイスに移行する場合は、手動で転送するか、再登録する必要があります。これは些細な手間にとどまることもあれば、数千人のユーザーを管理し、デバイスのアップグレードを担当者が手を動かさずに行いたい組織にとっては導入の障害になることもあります。

次の項目では、これらのモデルが重要な理由、それぞれのアプローチに伴うリスク、そして環境に合ったモデルの選び方を解説します。個人のサインインを保護する場合でも、会社全体でパスワードレスを展開する場合でも参考になるはずです。

デバイス間で同期されるパスキー: メリットとリスク

複数デバイスでの利便性: 同期されるパスキー (iCloud や Google パスワードマネージャーなど) を使うと、同じエコシステム内の任意のデバイスからすぐにサインインできます。電話、タブレット、ノート PC の間でシームレスな操作感が得られます。
自動的な回復: デバイスを紛失しても、パスキーは安全に保たれ、信頼できる別のデバイスから回復できます。ロックアウトの発生や、サポート担当者の負担を減らせます。
クラウド依存によるリスク: 資格情報は暗号化されていてもクラウドを経由して移動するため、同期プロバイダーが侵害されたりサービス停止に見舞われたりした場合のリスクが広がります。セキュリティの状態が第三者に左右されることになります。
プラットフォームの囲い込み: 同期は通常、Apple 製品同士、Google 製品同士など、同じエコシステム内で最も効果的に機能します。ユーザーが iOS、Android、Windows、macOS の間を行き来すると、摩擦が生じやすくなります。

ソフトウェアバインド型パスキーとデバイス同期のトレードオフ

ローカルのみのセキュリティ: このパスキーは単一のデバイスに強く紐付けられているため、サードパーティのクラウドが侵害されても露出することはありません。より厳格な分離が求められる環境に適しています。
移植性の制限: デバイスを切り替える場合は、パスキーを手動でエクスポート、移行、またはリセットする必要があります。手間は増えますが、攻撃対象となる範囲を減らせます。
回復の難しさ: デバイスを紛失したり故障したりすると、ローカルのパスキーも失われます。永続的なロックアウトを避けるには、安全なバックアップや明確な回復手順を計画しておくことが不可欠です。
ユースケースへの適合: 金融機関や政府機関など、高い保証レベルや規制要件を持つ組織では、運用の手間が増えても、特権アカウントや機密性の高いシステムにこの方式を採用することが多くあります。

ハードウェアセキュリティキーと外部認証システムの解説

ハードウェアセキュリティキーは、FIDO2 およびパスキーシステムでパスワードレス認証を行うための専用の物理デバイスです。USB、NFC、Bluetooth のドングルなど、さまざまな形状があり、キーホルダーに付けて持ち歩いたり、ワークステーションのそばに置いたりして使用します。代表的な製品には YubiKey、SoloKey、Feitian などがあります。

ハードウェアセキュリティキーを際立たせているのは、改ざんへの耐性を重視した設計です。暗号化された秘密情報 (秘密鍵) はデバイス内で生成され、接続先のコンピューターや電話が侵害された場合でもデバイスの外に出ることはありません。このため、フィッシング攻撃やマルウェアに対して非常に強く、管理者アカウント、ルートアカウント、重要度の高いアカウントに優先して使われています。

プラットフォームに依存するパスキーと異なり、ハードウェアキーは業界標準のClient to Authenticator Protocol(CTAP)を使用してデバイスやブラウザー API(WebAuthn など)と連携します。そのため、対象のアプリケーションが FIDO2 に対応していれば、Apple、Google、Microsoft のプラットフォームに限定されず、多くのシステムで一般に利用できます。

規制の厳しい分野や高リスクの業種では、コンプライアンスや AAL3 レベルのセキュリティ(NIST SP 800-63B で定義された最高水準の保証)のために、このようなキーの使用が義務付けられる場合があります。すべてのデバイス間で同期されるパスキーほど手軽ではありませんが、侵害が絶対に許されない役割に対して最高水準のセキュリティを提供します。

各段階における資格情報のライフサイクルとセキュリティ

FIDO2 とパスキーへの移行は、単にログイン画面を改善することだけが目的ではありません。資格情報のライフサイクル全体を通じてセキュリティを強化することが重要です。パスキーの初回作成から、利用、保管、失効に至るまでの各段階には、それぞれ異なる課題と攻撃対象領域があります。

このライフサイクルを理解すると、組織はセキュリティ制御とガバナンスをどこに重点的に適用すべきかを把握できます。たとえば、資格情報の作成では強力な証明(アテステーション)とバインディングが必要であり、利用時にはフィッシングやデバイス侵害の試みを監視しなければなりません。パスワードでは常に弱点となってきた保管とバックアップも、適切なデバイスバインド型の資格情報や堅牢なクラウド暗号化があれば、強みに変えることができます。

ライフサイクル管理には、地味ですが重要な領域も含まれます。ローテーション、失効、アカウント回復です。どのユーザーがどのキーを持っているかを把握し続けること、従業員の退職時に確実に整理すること、紛失または侵害されたデバイスに生産性を損なうことなく対応できることは、いずれも優れたパスワードレス運用の一部です。

Microsoft 環境では、強力な資格情報ライフサイクルの実践を、データガバナンスとアクセス戦略全体に組み込むことが重要です。その考え方は、Microsoft 365 Data Access Governance などの資料にも示されており、安全なコラボレーションには所有権、説明責任、レビュープロセスが欠かせません。

資格情報の作成、攻撃、状態管理

安全な作成: FIDO2 資格情報は、必ずハードウェアに裏付けられたキーストアで生成し、強力な証明(アテステーション)によって正規のデバイス発行元を確認してください。
フィッシング耐性: パスキーおよび FIDO2 の認証フローは、本質的にフィッシングに強い仕組みです。シークレットが送信されることはなく、署名用のチャレンジもセッションごとに一意だからです。
リプレイ攻撃および MITM 攻撃: 一意で一回限りの暗号化チャレンジにより、攻撃者が傍受した応答を再利用したり、中間者攻撃を成立させたりすることを防ぎます。
状態管理: 資格情報の状態を定期的に確認し、未使用または侵害されたキーは失効させ、特に特権アカウントや高いアクセス権を持つアカウントについては、在庫を適切に管理してください。

資格情報の回復、失効、および制約

完璧なシステムはありません。どれほど強力なパスキーやセキュリティキーであっても、紛失、盗難、故障が起こり得ます。特に、チームや組織全体で大規模にパスワードレス認証へ移行する場合は、資格情報の回復と失効を計画しておくことが不可欠です。

パスキーや FIDO2 資格情報を紛失した場合の回復方法は、その管理方式によって異なります。同期型パスキー(Apple の iCloud キーチェーンや Google パスワードマネージャーなど)の場合、デバイスレベルの認証と回復手順を完了すれば、通常は新しいデバイスに資格情報を復元できます。これによりダウンタイムは最小限に抑えられますが、クラウドプロバイダーのセキュリティと回復の仕組みに信頼を置くことになります。

セキュリティキーは管理がやや複雑です。ハードウェアキーを紛失した場合、事前に登録したバックアップキーがあるか、管理者による例外対応の手順が確立されている必要があります。そうでなければ、完全にアカウントからロックアウトされる可能性があります。失効はサーバー側で処理されます。キーを紛失として報告すると、公開鍵がプロファイルから削除され、紛失した資格情報は使用できなくなります。

一方で、バックアップおよび回復機能に過度に依存すると、セキュリティを損なう恐れもあります。回復プロセスは、ソーシャルエンジニアリングや内部脅威に対して強化しておく必要があります。定期的なレビューや、Microsoft Purview Audit などのツールによる自動化は、資格情報の利用状況、失効イベント、およびコンプライアンスや forensic 調査上のリスクを監視するのに役立ちます。

結局のところ、復旧と取り消しの戦略を選ぶことは、ユーザーの利便性と堅牢な統制のバランスを取ることであり、万能の答えはありません。デバイス紛失のシナリオを洗い出し、段階的なアカウント復旧の仕組みを導入することは、本格的なパスワードレス展開には欠かせません。

パスキーとセキュリティキー：適切な選択肢の選び方

選択の時が来たら、パスキーとハードウェアセキュリティキーのどちらを選ぶかは、利用シナリオ、ユーザーの利便性の要件、脅威の環境によって決まります。両者は FIDO2 プロトコルと公開鍵暗号という共通の基盤を持っていますが、日々の使い勝手は大きく異なります。

パスキーは、ユーザーが複数のデバイスでシームレスにアクセスする必要がある環境で力を発揮します。スマートフォン、タブレット、ノートPC、そして Microsoft 365 のようなクラウドアプリを使うエンドユーザーを想定してください。その強みは使いやすさにあります。デバイスのロックを解除するだけでサインインでき、個人用や業務用の複数のデバイスをまたいでも同様に使えます。

一方、セキュリティキーは最高水準のセキュリティを提供します。管理者、特権ユーザー、あるいは侵害のリスクを絶対に許容できない人にとって重要です。携帯性に優れるため、管理されていないデバイスや公共のシステムから認証する必要がある場面に最適です。ただし欠点もあります。持ち歩くのを忘れたり、紛失したり、壊れたりした場合、アクセスの復旧はより面倒になる可能性があります。

規制の厳しい業界や高リスクの環境では、セキュリティキーを（Zero Trust for Microsoft 365 で解説しているような）ゼロトラストのアプローチに組み込むことで、ユーザーの負担を抑えつつ、急速に変化する脅威モデルに対応した継続的な検証を実現できます。

エンタープライズおよび規制業界向けのアプリケーション：1Kosmos 1Key とその先

高い保証レベル向けの 1Kosmos 1Key： このソリューションは、NIST SP 800-63B の厳格な AAL3 要件を満たすように設計された、FIDO2 準拠のパスワードレス認証を提供します。特権ユーザーや高リスクのアカウントを対象に、生体認証による本人確認、デバイスの信頼性、動的な認証要素を組み合わせています。
エンタープライズ統合の強化： 1Key は Microsoft のビジネスプラットフォームとスムーズに統合され、ID のプロビジョニング、アクセスのライフサイクル管理、取り消しを自動化し、大規模なクラウド展開を支えます。
規制への準拠： このプラットフォームは、金融、医療、行政といった規制業界向けに、すぐに使える準拠マッピングを提供します。厳格な報告義務を満たす本人確認、堅牢なログ記録、監査証跡を実現します。
市民と従業員の安全なアクセス： クラウドアプリや市民向けポータルを展開する組織は、本人確認とガバナンスを維持しながらパスワードレスアクセスを実現できます。資格情報の紛失やパスワードリセットに伴う運用上の負担も軽減されます。
Power Platform とガバナンスの相乗効果： 1Key のようなソリューションを、より広範なガバナンスの枠組みに組み込むことで（Power Platform governance best practices で解説しているとおり）、ID を起点とするセキュリティを、エンタープライズのデータ、コネクタ、環境に関するポリシーと整合させることができます。

ユーザー体験とマルチデバイス認証の向上

ユーザーと管理者の意見が一致する点があるとすれば、それはパスワードがうんざりするものだということでしょう。パスキーは、サインインをシンプルで直感的、かつ負担の少ないものにすることで、この問題の解決を目指します。特に複数のデバイスやクラウドプラットフォームをまたぐ場合に効果的です。パスキーを使えば、複雑なフレーズを覚える必要も、四半期ごとの「セキュリティ意識向上」キャンペーンのたびにパスワードをリセットする必要もありません。

パスキーの大きな利点はマルチデバイス認証です。アカウントのキーチェーン（Apple、Google、Microsoft のいずれでも）に一度保存されると、エコシステムで連携したデバイス間でほぼ瞬時にサインインできます。顔認証や指紋による承認で済むため、処理が速くなるだけでなく、デバイスや場所を行き来するユーザーの負担も大幅に減ります。

導入の観点から見ると、負担の軽減が何より重要です。多くの IT チームは、強制されたパスワードポリシーによる反発や、ロックアウトに伴うヘルプデスクの問い合わせ増加を懸念しています。パスキーはこうした問題を抑えます。ユーザーはパスワード、ログインの繰り返しによる疲労、リセットの繰り返しに悩まされることがなくなります。導入の障壁は、エコシステムの互換性や初期のデバイス設定に関するものが中心であり、どちらも急速に改善が進んでいます。

賢い組織は、少人数のチームでパスキーをパイロット導入してフィードバックを集め、デバイスの登録を自動化することで、展開の優先順位を決めています。これにより、セキュリティを損なうことなく、プロセスを安定させ、ユーザーにとって使いやすい状態を保てます。

よくある質問、セキュリティキーとパスキーの比較、リモートアクセスの安全性

パスキーとセキュリティキーは同じものですか? 厳密には違います。パスキーはデバイスやクラウドで管理されるデジタルのFIDO2資格情報です。一方、セキュリティキーは、認証のために差し込んだりタップしたりする物理デバイスです。どちらも同じ暗号化の基盤を使用しています。
パスキーは Apple、Google、Windows のデバイスをまたいで使えますか? ある程度は使えます。同期されたパスキーは同じエコシステム内で最も効果的に機能します。真のクロスプラットフォーム対応も存在しますが、対応状況にばらつきがあることがあり、FIDO2 機能のブラウザー互換性も異なります。
パスキーをリモートで盗まれる可能性はありますか? デバイス(およびそのバックアップ用のクラウドアカウント)が侵害されない限り、パスキーをリモートで盗まれることはまずありません。鍵そのものが暗号化されていない状態でデバイスの外に出ることはないからです。
パスキーはリモートワークやクラウドアクセスに安全ですか? はい、デバイスポリシーや Microsoft Defender、Purview などのツールと組み合わせれば、パスキーは堅牢なリモート認証を提供し、フィッシング、マルウェア、ID 盗用によるリスクを大幅に低減します。
パスワードマネージャーはパスキーを保存できますか? 1Password、iCloud キーチェーン、Google パスワードマネージャーなどの最新版では、パスキーに対応しています。ただし、ID のフローに組み込む際は、必ず互換性と FIDO2/WebAuthn のサポートを確認してください。

まとめ、セキュリティの比較、最終的な推奨事項

セキュリティのポイント: パスキーも FIDO2 資格情報も、パスワードとその弱点を排除します。使いやすさの点では、ほとんどのユーザーにとってパスキーが優れていますが、ハイアシュアランスが求められる場面では、依然としてハードウェアのセキュリティキーが主流です。
使いやすさと携帯性: 同期されたパスキーは複数のデバイスでシームレスにサインインできるため、一般ユーザーや企業の端末群に適しています。ハードウェアキーは持ち運びができますが、物理トークンを常に携帯しておく必要があります。
展開戦略: 規制のある環境では、多層防御を実装してください。一般ユーザーにはパスキー、管理者にはセキュリティキーを組み合わせ、AAL3 に準拠したワークフローには 1Kosmos 1Key などのエンタープライズ向けソリューションを使用します。
ライフサイクルと復旧: 移行の前に、復旧と失効のワークフローを計画してください。ダウンタイムやコンプライアンスの逸脱を避けるには、バックアップと監査が不可欠です(Governance for AI and access control を参照)。
将来への備え: 相互運用性とコンプライアンスに関する標準の動向を注視してください。特に Microsoft 365 および Azure 環境では、新たな ID と脅威の課題に先手を打つことが重要です。

ID セキュリティに関する次のステップと学習リソース

Microsoft のドキュメント: Microsoft 365 および Azure におけるFIDO2、パスキー、パスワードレス展開に関する公式ドキュメントを確認してください。
ID セキュリティのポッドキャスト: M365.fm: Auditing User Activity with Microsoft Purview では、監査とガバナンスに関する実践的な議論を聴けます。
技術ガイド: 大規模な企業環境で FIDO2 およびパスキー認証を設定し、トラブルシューティングする方法について解説した技術ブログを確認してください。
コンプライアンスのベストプラクティス: NIST SP 800-63B を学習し、主要なパスワードレスソリューションが保証レベル(IAL、AAL)にどのように対応しているかを確認してください。
コミュニティフォーラム: セキュリティ、Microsoft 365、ID 管理のフォーラムに参加して、質問したり、実際の導入におけるヒントを同じ立場の人たちと共有したりしてください。

🎧 あわせて聴きたいエピソード

Microsoft Entra のアイデンティティガバナンス
Microsoft 365 における所有権とアクセス制御の実践的な方法を学びます。
Microsoft 365 ガバナンス運用モデル
テクノロジーの導入を持続可能にする判断のポイントを解説します。
AI エージェントをわかりやすく解説
AI を活用した業務におけるガバナンスの前提を理解できます。

パスキーと FIDO2:企業向けの実践的なガイダンス

パスキーと FIDO2 セキュリティキーは、いずれもフィッシングに強い認証を提供します。ただし、移行性、回復、デバイス管理、ユーザー体験の面でトレードオフが異なります。効果的な展開では、資格情報モデル、登録プロセス、回復プロセス、特権ユーザーの要件、レガシーアプリケーションの例外を明確に定義する必要があります。

実装チェックリスト

ID プロバイダー、ブラウザー、デバイス、対応アプリケーションを洗い出します。
リスクプロファイルごとに、同期型かデバイスバインド型かの資格情報を選択します。
強制適用の前に、複数の認証子を登録します。
回復手順とヘルプデスクでの本人確認を保護します。
特権ユーザーでパイロット運用を行い、広範な展開の前に失敗を測定します。

よくある間違い

回復手段を用意しないまま、パスワードレスサインインを強制すること。
すべてのブラウザーとレガシーアプリケーションが同じ資格情報をサポートしていると思い込むこと。
共有の認証子を許可し、責任の所在を曖昧にすること。
デバイスのライフサイクルや認証子紛失時の手順を無視すること。

よくある質問

パスキーとは何ですか。

パスキーは公開鍵暗号方式を使用する FIDO の資格情報で、デバイスのジェスチャー、生体認証、またはローカル PIN によってロックを解除します。

FIDO2 とは何ですか。

FIDO2 は、WebAuthn と Client to Authenticator Protocol を中核とする認証標準で、フィッシングに強いサインインを可能にします。

パスキーと FIDO2 は同じものですか。

パスキーは、FIDO 標準に基づいたユーザーにとって分かりやすい資格情報のエクスペリエンスです。FIDO2 は、より広範な技術エコシステムと認証プロトコルを指します。

パスキーはパスワードより安全ですか。

はい。パスキーはオリジンに紐づいた公開鍵暗号方式を使用するため、攻撃者が盗んだり再利用したりできる秘密情報が Web サイトに渡ることはありません。

パスキーはフィッシングに強いですか。

適切に実装されていれば、はい。資格情報は正規の Web サイトのオリジンに紐づけられており、フィッシングページにパスワードを明かすことはありません。

YubiKey は FIDO2 のパスキーですか。

YubiKey は FIDO2 の資格情報を保存でき、セキュリティキーとして機能します。それをパスキーと呼ぶかどうかは、資格情報と製品の用語によります。

パスキーは YubiKey より安全ですか。

どちらが常に安全だということはありません。同期型のパスキーは回復性と使いやすさを高め、ハードウェアにバインドされたキーは強力なデバイス管理と分離を提供します。

同期型パスキーとは何ですか。

同期型パスキーは、承認された資格情報マネージャーやプラットフォームエコシステムを通じてバックアップされ、複数のデバイスで利用できるパスキーです。

デバイスバインド型パスキーとは何ですか。

デバイスバインド型パスキーは 1 つの認証子またはデバイスに残り、別のプラットフォームには同期されません。

FIDO2 はパスワードを完全に置き換えますか。

対応しているアプリケーションではパスワードを置き換えられますが、組織では依然として回復、レガシー認証、アカウントのライフサイクルに関する戦略が必要です。

Microsoft Entra ID はパスキーをサポートしていますか。

Microsoft Entra ID は、テナントの構成と現在のサービス機能に応じて、FIDO2 セキュリティキーとパスキー関連の認証オプションをサポートします。

WebAuthn はパスキーとどのような関係がありますか。

WebAuthn は、Web サイトや ID プロバイダーが公開鍵の資格情報を作成して使用できるようにする、ブラウザーおよびプラットフォームの API です。

ユーザーがパスキーのデバイスを紛失した場合はどうなりますか。

ユーザーには、別の登録済み認証子または承認された回復手段が必要です。企業は、パスワードレスアクセスを強制する前に、複数の認証子を登録しておく必要があります。

パスキーは複数のデバイスで使用できますか。

同期型パスキーは、対応しているデバイス間で利用できます。デバイスバインド型の資格情報は、認証子ごとに登録が必要です。

パスキーはユーザー間で共有できますか。

いいえ。資格情報は 1 人の個人または承認されたワークロード ID を表すべきです。認証子を共有すると、責任の所在が曖昧になります。

パスキーは資格情報の再利用攻撃から保護しますか。

はい。秘密鍵は認証子に残り、認証のたびにチャレンジが含まれるため、単純な再利用は防止されます。

パスキーは盗まれることがありますか。

攻撃者がデバイスを盗む可能性はありますが、資格情報は通常ローカルのロック解除要素で保護されており、再利用可能なパスワードが露出することはありません。

パスワードレス認証とは何ですか。

パスワードレス認証は、記憶したパスワードの代わりに、暗号化された認証子、生体認証、PIN、またはセキュリティキーを使用してユーザーを検証します。

パスキーのデメリットは何ですか。

回復、プラットフォーム間の相互運用性、共有デバイスでの利用、レガシーアプリケーション、展開時のユーザーの理解不足などが課題になります。

企業はパスキーの回復をどのように扱うべきですか。

複数の認証子を必須とし、ヘルプデスクでの本人確認を定義し、回復手段を保護し、登録とリセットのイベントを監視します。

パスキーはモバイルデバイスでも使用できますか。

はい。対応しているモバイルOSでは、プラットフォーム認証機能または外部のセキュリティキーを使ってパスキーを作成し、利用できます。

パスキーはブラウザーをまたいで機能しますか?

対応状況は、ブラウザー、OS、IDプロバイダー、資格情報の種類によって異なります。展開前に、対象ユーザーの利用シナリオをテストしてください。

パスキーは管理者に適していますか?

はい。特に特権ユーザーにとって有用です。特権ユーザーはフィッシングに強い認証を使い、管理用のIDを通常のIDと分けて運用する必要があります。

パスキーは条件付きアクセスにどのように影響しますか?

IDプロバイダーが認証機能を認識し、ポリシーの条件を満たしていれば、強力な認証の要件を満たすことができます。

パスキーはどのように展開すべきですか?

特権ユーザーと侵害リスクの高いユーザーから始め、復旧手段を確立します。その後、代表的なデバイスで試験導入し、登録状況とサポートの指標を確認しながら対象を広げてください。

展開後に監視すべき項目は何ですか?

登録状況、認証の失敗、復旧イベント、ポリシーの回避、ヘルプデスクへの問い合わせ件数、サインインのリスクを監視してください。

パスキーを使えば MFA は不要になりますか?

パスキーは、認証機能の所持と端末のローカルロック解除の要素を組み合わせることで、フィッシングに強い多要素認証の体験を提供できます。

パスキーはサービスアカウントを保護できますか?

人間向けのパスキーは、ワークロードIDの代わりにはなりません。サービスには、マネージドID、証明書、その他適切な非人間用の資格情報を使用してください。

企業にとっての主なメリットは何ですか?

主なメリットは、フィッシングやパスワード再設定のリスクを減らしながら、サインインのセキュリティとユーザー体験を向上させられる点です。

最初の導入ステップは何ですか?

アプリケーションとユーザーを棚卸しし、IDプロバイダーの対応状況を確認し、復旧手順を定義したうえで、小規模なグループで試験導入してから、パスワードレスサインインを強制してください。

関連する M365.fm のリソースもご覧ください: M365.fm Learning Hub、Microsoft 365 governance checklist、Microsoft Copilot security model。