「MFA（多要素認証）は導入済み。次はパスワードそのものをなくすパスキーへ」──そんな検討を始めた情シスの方も多いのではないでしょうか。

パスキー（Passkeys）は、公開鍵暗号を使うパスワードレス認証のための認証情報です。利用時には生体認証やPINなどで認証器のロックを解除します。フィッシングに強く、ユーザーの負担も減らせるというメリットがあります。GoogleやApple、Microsoftといった大手プラットフォームが推進しており、企業でも移行が検討されています。

しかし、企業導入の現場では話がそう単純ではありません。パスキー認証そのものは堅牢でも、同期パスキーの管理範囲、残存するパスワード、登録時の本人確認、端末紛失時などの復旧手順など、設計を誤ればかえって穴をつくってしまう論点がいくつもあるからです。

本記事では、企業導入時に見落とされがちな四つの落とし穴を整理した上で、導入前に確認すべき設計要件と、無理のない段階的な移行の進め方を解説します。パスキーの基本的な仕組みについては関連記事で解説していますので、本記事ではそこから一歩踏み込み、「導入する側」の視点に絞ってお届けします。

【関連記事】

パスワードレスのセキュリティを実現するPasskeys（パスキー）とは？

なぜパスキーは「フィッシングに強い」のか？ 2種類のパスキーを知る

パスキーは、認証規格「FIDO2」に基づく仕組みです。ログイン時はパスワードを入力する代わりに、スマートフォンやPC、セキュリティキーなどの認証器で、指紋・顔認証やPINによる本人確認を行います。裏側では「秘密鍵」が署名を行い、サービス側があらかじめ登録された「公開鍵」で検証します。秘密鍵そのものをログイン先のサービスへ送ることはありません。ただし、後述する同期パスキーでは、秘密鍵が暗号化された上で複数端末へ同期されます。

この方式では、サービス側に認証用の秘密鍵を保存せず、公開鍵で署名を検証します。公開鍵が漏えいしても、それだけで本人の署名を作ることはできません。また、認証情報は正規サービスのドメインに紐付くため、別ドメインの偽サイトでは同じ認証情報を利用できず、フィッシングによる認証情報の窃取を防ぎやすくなります。ただし、登録・復旧など別の経路の対策も必要です。

ただし、企業導入を考える上で必ず押さえておきたいのが、パスキーには性格の異なる二つのタイプがあるという点です。

パスキーの二つのタイプ

タイプ	特徴	主な例
同期パスキー	クラウドなどを通じ、同一の管理アカウントに紐付く複数端末へ暗号化して同期される	iCloudキーチェーン、Googleパスワードマネージャー
デバイス固定パスキー	特定の認証器に保存され、ほかの端末へ同期されない	FIDO2セキュリティキー、Windows Hello for Business

個人利用で急速に広がっているのは前者の「同期パスキー」です。スマートフォンを買い替えても引き継げる手軽さが魅力ですが、企業利用ではこの「同期される」という性質そのものが論点になります。詳しくは次章で見ていきましょう。

「パスキー＝安全」とは言い切れない。企業導入で見落としやすい4つの落とし穴

「パスキーを導入すれば、認証まわりの心配は全くなくなる」と考えてよいのでしょうか。

残念ながら、必ずしもそうとは言い切れません。企業導入で見落としやすいポイントを、4つの観点で整理します。

落とし穴1：同期パスキーが「会社の管理外」に広がる

前章で触れた同期パスキーは、Apple AccountやGoogleアカウントなどを経由して、同一アカウントに紐付く複数の端末に同期されます。これは裏を返せば、業務システムにログインするための鍵が、会社の管理していない私物端末にもコピーされ得るということです。例えばAppleのパスワード共有グループでは、パスキーをほかのメンバーと共有できるため、利用するサービスの共有機能も確認が必要です。

もちろん、同期パスキーが一律に危険というわけではありません。ただし、管理端末を配るだけで同期先まで制御できるとは限りません。利用する認証基盤で許可する認証器や同期の範囲を制限できるか確認し、必要な統制を満たせない用途ではデバイス固定型を選ぶなど、自社の方針を導入前に決めておく必要があります。

落とし穴2：パスキー化できない経路に、パスワードが残り続ける

パスキーで守れるのは、パスキーに対応した認証経路だけです。

Microsoft Entra IDやIDaaSといったID基盤へのログインはパスキー化できても、その基盤を経由せず個別にログインしている業務システムやSaaS、古い認証方式しか持たないメールソフトやVPNなどは、従来どおりパスワードで動き続けます。「全社パスキー移行」を掲げたのに、蓋を開けてみればパスワードだらけ──という事態も起こり得ます。この状態では、パスワードの漏えいや使い回しなどのリスクも残ります。

また、パスキーに対応した経路でも、パスワードによるログインが有効なままなら、攻撃者はその経路を狙えます。登録と復旧の準備ができた対象から、パスワードなどの不要な認証経路を無効化することが重要です。パスキー化できないシステムには、利用可能な多要素認証やアクセス制限・監視を適用し、移行・廃止の期限を管理します。

落とし穴3：登録・再登録時の本人確認が甘いと、入口から乗っ取られる

意外と見落とされがちなのが、パスキーの登録・再登録を許可する際の本人確認です。具体的には、入社時にはじめてパスキーを登録するとき、PCやスマートフォンの買い替え・機種変更で登録し直すとき、そして端末の紛失・故障を受けて再登録するときなど、ユーザーのライフサイクルの中で、登録の場面は何度も訪れます。

本人確認が不十分な状態で登録を許せば、攻撃者が本人になりすまして手続きし、自身の端末に正規のパスキーを登録できてしまいます。その後はパスキー認証自体が成功するため、認証方式だけでは不正を防げません。情シスは、登録を許可する認証器の方針と合わせ、誰がどのように本人確認を行うかを設計しておくことが欠かせません。

落とし穴4：アカウント復旧フローが認証の弱点になる

そして最後が、端末の紛失・故障などでパスキーを利用できなくなった場合の復旧フローです。復旧時の本人確認が弱ければ、パスキーで防いだはずのなりすましが、別の経路から成立するおそれがあります。

認証の強度は、平常時のログインではなく、復旧経路を含めた全体の中で最も弱い部分で決まります。せっかくログインをパスキー化しても、復旧手段がSMS認証や秘密の質問のままなら、攻撃者はそこを狙えばよいだけです。実際、海外ではヘルプデスクに退職者や社員になりすまして電話をかけ、認証手段をリセットさせて侵入する手口が大きな被害を生んでいます。

パスキー導入では、平常時のログインだけでなく、登録と復旧を含む認証運用全体を設計する必要があります。

この認識を持てるかどうかが、安全な運用を考える上で重要です。

導入前に確認したい！4つの落とし穴に対応する4つの設計要件

ここまで見てきた4つの落とし穴は、いずれも導入前の設計によってリスクを減らせます。それぞれの落とし穴に対応する設計要件を、4つの観点として整理します。社内での要件定義や、ベンダーとの対話の出発点として活用してください。

【観点1】デバイスと認証手段の方針──同期パスキーの管理外拡散を防ぐ

落とし穴1（同期パスキーの管理外拡散）を防ぐために重要なのが、「どの認証手段を、どの端末で許可するか」という方針策定です。同期型・デバイス固定型の選択と、どの機器を認証器として使うかは別の軸です。代表的な機器の選択肢を三つ挙げます。

一つ目は、業務PCそのものを認証器として使う方法です（Windowsなら「Windows Hello for Business」など）。TPMなどに鍵を保管し、顔認証やPIN（暗証番号）でログインします。要件を満たす既存PCを活用できるのが利点です。PCでもパスワードマネージャーを使う場合には同期型になり得るため、採用する方式を明確にします。

二つ目は、セキュリティキーです。USBメモリのような形をした専用デバイスに鍵を保管します。鍵を機器に固定して管理できる一方、会社が調達して一人一人に配る必要があります。

三つ目が、スマートフォンを認証器として使う方法です。利用する機能によって同期型にもデバイス固定型にもなります。MDM（Mobile Device Management：モバイル端末管理）は端末管理に役立ちますが、それだけでパスキーの同期先まで制限できるとは限りません。対応する認証基盤やアプリの設定を確認し、会社の方針に沿って利用させる必要があります。

選び方の目安としては、管理者など重要な権限を持つアカウントではデバイス固定型を優先し、一般業務では管理・復旧の要件を満たす範囲で同期型も検討する、といった方針が考えられます。その上で、既存の業務PC、セキュリティキー、業務用スマートフォンの対応状況と費用を比較します。

【観点2】既存のID基盤との連携──パスワードの残存範囲と連携への影響を把握する

落とし穴2（残存パスワード）への対策は、今使っているID基盤との噛み合わせを確認するところから始まります。

社内の業務システムとSaaSを一覧化し、「ID基盤経由でログインしているもの」「個別ログインのもの」「古い認証方式しか使えないもの」に仕分けましょう。

その上で、パスキー化できる経路とできない経路を整理し、できない経路については、ID基盤への統合・例外としての台帳管理・廃止のいずれで扱うかを決めていきます。例外を残す場合は、多要素認証、接続元の制限、ログ監視などの代替策と、移行・廃止の期限も定めます。

例えばMicrosoft環境では、Entra ID経由の認証にパスキーを利用できます。対象ユーザーとアプリの対応を確認した上で、条件付きアクセスの認証強度などによってフィッシング耐性のある方式を要求すれば、対象経路で弱い認証へ戻るのを防ぎやすくなります。基盤を経由しない個別ログインには、別途対策が必要です。

注意したいのが、自社のサーバー室などで社員IDを管理してきた「オンプレミスのActive Directory（AD）」が残っている場合です。

社内のファイルサーバーなどがADの認証を利用している場合、パスワードレスでアクセスするための連携方式や構成要件を確認する必要があります。そのため、両者の連携設定が不十分だと、「パスキーでログインはできたのに、社内のファイルサーバーが開けない」といったことが起こり得ます。パスキー導入後も社員が今まで通り社内資産にアクセスできるかを、本番展開の前に実際に試して確かめておくと安心です。

【観点3】登録フローとユーザーへの浸透──なりすまし登録を入口で断つ

落とし穴3（登録時の乗っ取り）を防ぐには、登録できるのは本人だけ、という状況をどのように担保するのかが問われます。

例えばMicrosoft Entra IDでは、本人確認を経て一時アクセスパス（TAP）を発行し、パスキーなどの登録に利用できます。TAPは有効期間と一回・複数回の利用を設定できるため、用途に合わせて短い期間や一回限りの利用に制限します。登録手順をどこまで制御できるかは認証基盤やSaaSによって異なるため、対応する手順を導入前に確認しましょう。

SMSやメールで送られるワンタイムパスワードは、それだけで本人確認が万全になるわけではありません。いずれもフィッシングによって認証コードを盗まれるリスクがあり、SMSではSIMの不正な再発行などにも注意が必要です。

TAPなどの一時コードも、それ自体がフィッシングに強い仕組みではありません。情シスが本人を確かめた上で安全に受け渡し、利用可能な時間や回数を制限する運用を組み合わせることが重要です。

【観点4】復旧フローとアカウントのライフサイクル──非常時の認証の弱点を減らす

そして、落とし穴4（復旧フローの脆弱性）に対応するのが、非常時の設計です。

有効な対策の一つは、通常用と予備用を合わせて複数の認証手段を登録しておくことです。例えば、通常用の認証器に加えて予備のセキュリティキーを登録すれば、一つが使えなくなった場合も、残る認証手段でログインして再登録できるように設計できます。

また、それでも復旧が必要になった場合に備えて、ヘルプデスク経由の本人確認手順も固めておきます。上長の承認を挟む、対面やビデオ通話で確認する、管理済み端末からの申請に限るなど、なりすましによる復旧申請に耐えられる手順になっているかが確認のポイントです。

あわせて、退職・異動時にパスキーを確実に失効させる手順も、退職フローに組み込んでおきましょう。

段階的移行シナリオ──「一斉切り替え」ではなく4つのフェーズで

設計要件が整理できたら、いよいよ移行計画です。ここで強調しておきたいのは、全社一斉の切り替えは避けるべきだということ。認証はすべての業務の入口であるだけに、トラブル時の影響が大きく、段階的に対象を広げることで影響を確かめやすいためです。一方、段階移行ではパスワードとの併存期間が生じるので、前述の残存経路の管理も必要になります。

そこでおすすめしたいのが、影響の小さいところから試し、確かめながら対象を広げていく段階移行です。具体的には、次の4つのフェーズに分けて進めます。

パスキー移行の4フェーズ

フェーズ	主な内容
0：現状把握と方針決定	認証経路の棚卸し／許可する認証手段、登録・復旧フローの設計
1：管理者から適用	事前検証の上、特権アカウントへパスキーなどのフィッシング耐性認証を適用
2：一般ユーザーへ展開	部門単位で段階展開／登録率の可視化とフォロー
3：準備が整った対象からパスワードを無効化	登録・復旧を確認した対象の弱い認証経路をブロック／例外の対策と期限管理

上記は「準備 → 限定した対象で検証 → 展開 → 不要な認証経路の無効化」という流れです。無効化は全社展開を待たず、登録・復旧と業務への影響を確認できた対象から進めます。それぞれのフェーズの狙いを見ていきましょう。

フェーズ0（現状把握と方針決定）

全体の設計図を描く段階です。前章の4つの設計要件を確認しながら、認証経路の棚卸しを行い、最終的にパスワードを無効化するのか、同期パスキーをどこまで許容するのかといった方針を、セキュリティ部門や経営層と合意しておきましょう。ここを飛ばして走り出すと、後のフェーズで手戻りが発生するため、意識してじっくりと進めておきたいフェーズです。

フェーズ1（管理者から適用）

管理者などの特権アカウントは、乗っ取られた場合の被害が大きく、扱う情報や権限も重要なため、優先して保護すべき対象です。ただし、少人数であっても影響は小さくありません。検証用アカウントなどで動作と復旧を確かめ、緊急時のアクセス手段を用意した上で対象を限定して適用します。その過程で、認証手段の展開方法や復旧手順を本格展開に向けて確認します。

フェーズ2（一般ユーザーへ展開）

一般ユーザーへの展開では、ユーザーへの説明もあわせて行いましょう。パスキーは「パスワードを覚えなくてよくなる」歓迎すべき変化ですが、「生体情報が会社に送られるのでは」といった誤解も生まれがちです。指紋や顔のデータは端末の外に出ないことを含め、平易な説明資料を用意しておくと、展開がぐっとスムーズになります。

ここは、対象がぐっと増える正念場です。いきなり全社員を対象にするのではなく、部門単位で順に広げていきましょう。ここで効くのが、登録期限を区切る・部門ごとの登録率を可視化する・未登録者へのフォローを仕組み化する、という3点です。「都合のいいときにどうぞ」と任せるだけでは登録は進まず、併存期間がずるずる延びてしまいかねません。部門ごとの展開とフォローには時間が必要です。フェーズ0で周知・サポート体制を計画し、フェーズ1で手順を確かめてから一般ユーザーへ展開しましょう。

フェーズ3（パスワードの無効化）

登録と復旧の準備が整い、業務への影響を確認できたユーザーグループやシステムから、パスワードやSMS認証などの不要なログイン経路を段階的にブロックします。これにより、パスキーを回避して弱い認証経路を狙われるリスクを減らせます。パスキー化できない古いシステムは例外として台帳に載せ、代替策を講じながら、ID基盤への統合やシステム更新・廃止で順次解消します。

移行期間は自社の条件に合わせて設定する

導入にかかる期間は、企業の規模、認証経路の数、システムの複雑さによって大きく変わります。

ID基盤が統合され、対応する端末がそろっている企業と、古い業務システムや個別ログインが多い企業では、必要な準備が異なります。棚卸しの結果を基に、検証、端末の準備、利用者への説明、復旧訓練に必要な期間を見積もりましょう。

重要なのは、期間の長さそのものではありません。フェーズ1までを早めに終えて最もリスクの高い特権アカウントを先に守り、残りは自社のペースで着実に広げていくという順番さえ守れば、たとえ全体に時間がかかっても、危険度の高い部分は早い段階で手当てできます。「全社への展開を急ぐこと」より「危ないところから順に固めること」を優先する、と考え着実に対処を進めましょう。

パスキー移行は、自社の認証設計を総点検する好機

パスキーは、フィッシングをはじめとするパスワード認証のリスクを減らす有力な選択肢です。ただし、認証方式の強さだけで安全性が決まるわけではありません。同期パスキーの管理範囲、残存するパスワード、登録時の本人確認、そしてアカウント復旧の手順まで含めて、自社の認証設計を整える必要があります。

裏を返せば、パスキー移行の検討は、自社の認証まわりを総点検する絶好の機会でもあります。どこにどんなログイン経路があり、いざというときに誰がどう復旧するのか。その全体像を描くところから、パスワードレスへの第一歩を踏み出してみてはいかがでしょうか。