パスキーの企業導入では、対象の業務で登録・ログインできることと、端末を失っても安全に復旧できることをセットで確認します。社員のスマートフォンで一度ログインできただけでは、全社移行の判断材料として不十分です。
この記事では、社内システムや業務用SaaSの利用者認証を対象に、保存方式の選び方と導入前の確認表をまとめます。以下の確認表と運用手順は、一次資料を踏まえた設計案です。実際の採否は、自社の端末管理方針と利用サービスの仕様に照らして決めてください。
パスキーとは：パスワードの代わりになる認証情報
パスキーはFIDO標準に基づく認証情報で、公開鍵暗号を使った認証を行います。利用時には、端末の顔・指紋認証やPINなどで操作します。生体情報そのものをログイン先のサーバーに送る仕組みではありません。FIDO Allianceはパスキーをフィッシング耐性のある認証手段として説明しています。出典：FIDO Alliance「Passkeys」
企業の導入判断では、認証方式の強さに加え、誰が登録を認めるか、どの端末に保存してよいか、失ったときに誰が本人確認するかまでを対象にします。パスキーを有効にする作業と、社内の認証運用を決める作業を一緒に進めましょう。
同期型と端末固定型は、復旧の条件で比較する
パスキーには、プロバイダーを通じて複数端末に同期する方式と、特定の端末・セキュリティキーに固定する方式があります。同期型では同期先アカウントの保護・復旧も評価対象です。端末固定型では、紛失後の再発行や旧認証情報の失効など、企業側の対応を要する場合があります。出典：FIDO Alliance「High Assurance Enterprise FIDO Authentication」2.3
| 比較する点 | 同期型で決めること | 端末固定型で決めること |
|---|---|---|
| 保存先 | 許可するプロバイダーとアカウントの管理主体 | 許可する端末・セキュリティキーと配布担当 |
| 端末紛失 | 同期済みの別端末や同期先アカウントにアクセスできるか | 予備の認証手段を持たせるか、再登録で復旧するか |
| 個人端末 | 私物端末への同期を認めるか | 私物端末への登録を認めるか |
| 退職・契約終了 | 業務アカウント側でアクセスを止める手順 | アクセス停止に加え、貸与した認証器の回収手順 |
これは優劣の表ではなく、運用方針を記入するための表です。一般社員と管理者で要求が異なるなら、同じ方式に統一することを先に目標とせず、それぞれの許可条件を定めます。
対応端末は「登録」と「日常利用」を分けて試す
対応状況は、OSの名前だけで判断しないでください。たとえばMicrosoft Entra IDの公式対応表は、OS・ブラウザー・ネイティブアプリの条件を分けて示し、サインインとは別にセキュリティキーの新規登録の制約も記載しています。この表はEntra ID向けであり、他サービスの対応を保証するものではありません。出典：Microsoft Learn「Passkey (FIDO2) authentication matrix」
対象業務ごとに、次の表を埋めて実機で確認します。仕様の確認日と検証担当も一緒に残すと、端末更新時の再確認に使えます。
| 確認項目 | 記入する内容 | 試行で確かめる操作 |
|---|---|---|
| 認証先 | サービス名、認証基盤、対象利用者 | 目的の業務画面へログインする |
| 利用環境 | 端末機種、OS・ブラウザー・アプリのバージョン | 社給PC・スマートフォンなど実際の組合せで使う |
| 初回登録 | 登録可能な環境、本人確認、登録担当 | 未登録の利用者が登録を完了する |
| 保存方式 | 同期型／端末固定型、許可する保存先 | 想定した保存先に登録できることを確認する |
| 端末間の利用 | スマートフォン持込み、カメラ・Bluetooth利用の可否 | 社内の制限を適用した状態で試す |
| 例外環境 | 共有PC、リモート環境、外出先など | 通常端末以外で必要な業務を行う |
| 復旧 | 連絡窓口、予備手段、承認者 | 主端末を使えない状態から再登録する |
スマートフォンのパスキーを別のPCのログインに使うFIDOのクロスデバイス認証では、QRコードを用い、Bluetooth Low Energyで近接を確認します。採用する場合は、カメラやBluetoothを制限した現場でも使えるかを確認項目に入れます。出典：FIDO Alliance「Passkeys」クロスデバイス認証の説明
復旧経路は「スマートフォンを失った後」から考える
復旧設計では、同期先に入れる場合と、すべての認証手段を失った場合を分けると、必要な対応が明確になります。主端末が使えないときに、その端末だけで受け取れる確認通知を必須にしていないかも点検しましょう。
次の順序を運用手順のひな型として使えます。
- 紛失の受付：本人が業務アカウントにログインできなくても連絡できる窓口を決める。
- 本人確認：申告者の確認方法と承認者を定め、確認が済まない場合の扱いも書く。
- 利用停止の判断：紛失した認証情報と既存セッションについて、停止・失効の要否を判断する担当を決める。
- 代替手段で復旧：事前登録した予備手段、または認証基盤が提供する再登録手順を使う。暫定手段を使う場合は有効期限も管理する。
- 新しい認証手段の確認：再登録後のログインを試し、古い登録や暫定手段の整理、対応記録まで終える。
各操作が実際に可能かは、認証基盤の管理機能で確かめます。特に「パスキーを削除する操作」と「ログイン済みの利用を止める操作」を混同しないよう、操作対象を手順に明記してください。
端末の故障、紛失、機種変更、退職は分けて試行します。機種変更なら旧端末を使える間に確認できますが、紛失の訓練では旧端末を使わずに復旧できるかを判定します。同期型を採用する場合も、同期先アカウントに入れない状況を試行対象から外さないことが大切です。
全社展開の前に、移行できる範囲を決める
最初の試行では、一つの業務と担当部門を選び、登録から復旧までを通して実施します。結果は「成功した人数」だけでなく、失敗した環境と必要だった支援を残します。
全社展開の判定には、次の項目を使えます。
- 対象の端末・ブラウザー・アプリで登録とログインを確認した。
- 主端末を使わずに復旧でき、本人確認と再登録の担当が決まっている。
- 退職や契約終了時に業務アカウントのアクセスを止める手順がある。
- 未対応の利用者に残す認証手段、例外の期限、再確認日が決まっている。
- 利用者向け案内と問い合わせ窓口を用意した。
従来の認証手段を止める判断は、この確認を終えてから行います。外部に設計や検証を依頼する場合も、対象業務、端末一覧、保存先の方針、復旧の承認者を渡せる状態にしておくと、依頼範囲を具体化できます。