「パスワードより安全なら、パスキーへ切り替えよう」

その判断自体は合理的です。

パスキーは、従来のパスワードのように、利用者が秘密の文字列を覚えてウェブサイトへ入力する仕組みではありません。公開鍵暗号を利用し、利用者は端末の生体認証、PIN、パターンなどでサインインを承認します。

パスキーは登録したウェブサイトやアプリのドメインに結び付くため、偽サイトへ認証情報を入力させる一般的なフィッシング攻撃に強いという特徴があります。生体情報を使用する場合も、生体情報そのものが認証先のサーバーへ送信される仕組みではありません。

しかし、パスキーを有効にしただけでは、会社の認証管理が完成したとはいえません。

実際の運用では、次の問題が発生します。

  • パスキーを登録したスマートフォンを紛失した
  • パソコンが故障し、交換することになった
  • 担当者が退職した
  • 管理者が長期入院して連絡できない
  • 個人のクラウドアカウントに業務用パスキーが同期されていた
  • 予備の認証手段がなく、管理画面へ入れない
  • 復旧方法として残していたメールやSMSが攻撃者に悪用された
  • パスキーを登録した本人は分かるが、会社として管理状況を把握していない

パスキーは、フィッシングに強い認証技術です。

一方で、誰に発行するか、どの端末に保存するか、端末を失ったらどうするか、退職時にどう無効化するかといった運用を、自動的に決めてくれるものではありません。

本記事では、パスキーの導入そのものではなく、導入後に会社が困らないための運用設計を解説します。

2026年は「パスキーを使うか」から「どう管理するか」へ移る年

FIDO Allianceは2026年5月、世界で利用されているパスキーが推計50億件に達したと公表しました。同時に、企業では導入後の端末管理、復旧、日常利用をどのように定着させるかが次の課題になっていると説明しています。これはFIDO Allianceによる推計であり、全世界のパスキーを一件ずつ実測した数字ではありませんが、パスキーが一部の先進企業だけの技術ではなくなったことを示しています。

英国のNational Cyber Security Centreは2026年4月、対応するサービスではパスキーを使用することを推奨する方針を公表しました。同機関は、パスキーを含むFIDO2認証について、一般に観測される認証情報への攻撃に対して、従来型の多要素認証と同等以上の安全性を持つと評価しています。一方で、端末、認証情報管理サービス、復旧手段を適切に管理する必要があるとも説明しています。

Microsoftも、2026年7月21日更新の公式文書で、Microsoft Entra IDにおける認証方法の変更予定を公表しました。

公式文書では、2026年9月1日から、SMSまたは音声認証の対象となっている利用者について、パスキーが自動的に有効化され、登録を促す仕組みが開始されるとされています。さらに、2027年2月1日には、Microsoftが直接提供するSMS・音声認証が終了する予定です。2026年9月1日の時点で直ちにパスキー登録が強制されるわけではありませんが、2027年2月1日以降、SMS・音声しか利用できない利用者には、パスキー登録を求めるスキップ不可の画面が表示される予定です。

Microsoft 365を利用している会社では、「パスキーを導入するかどうか」を考えるだけでなく、端末紛失時の復旧、登録できない利用者への支援、管理者の予備手段を決める時期に入っています。

パスキーには二つの保存方式がある

パスキーの運用を考えるときは、最初に「同期型」と「デバイス固定型」を区別します。

種類仕組み主な特徴主な注意点
同期型パスキー認証情報管理サービスを通じて複数端末へ同期する端末を交換しても、同じ管理サービスへサインインすれば利用できる場合がある同期先アカウント、登録端末、復旧方法の管理が必要
デバイス固定型パスキー特定の端末やセキュリティキーに保存する認証情報が特定の機器から移動しない機器の故障・紛失に備えた予備が必要

FIDO Allianceは、クラウドサービス等を介して利用者の端末間で同期されるものを「synced passkey」、単一の端末から出ないものを「device-bound passkey」と説明しています。FIDO対応のハードウェアセキュリティキーも、デバイス固定型パスキーを保存する手段になります。

同期型パスキーでは、利用者が新しい端末で同じパスキー管理サービスへサインインすると、パスキーを利用できる場合があります。

そのため、一般従業員が複数の会社端末を利用する環境では、利便性の高い選択肢となります。

ただし、パスキーが個人用のApple Account、Googleアカウント、パスワード管理サービスなどへ同期される構成では、会社が認証情報の保存先をどこまで管理できるかを確認しなければなりません。

米国NISTのSP 800-63B-4は、米国連邦機関向けの同期型認証器の要件として、組織が管理するアカウント、端末管理、未承認端末や未承認の同期先への移動を防ぐ制御などを挙げています。これは日本企業へ直接適用される法的義務ではありませんが、「業務用パスキーを個人管理の同期先へ保存してよいか」を企業が決める必要があるという点は、中小企業にも参考になります。

一方、デバイス固定型パスキーでは、登録した端末やセキュリティキーを失うと、そのパスキーを別の端末へ復元できない場合があります。

重要な管理者アカウントでは、安全性を重視してデバイス固定型を選ぶことがありますが、その場合は予備の認証器を用意しなければ、管理者本人が会社を締め出す結果になりかねません。

「どちらが安全か」ではなく、業務ごとに選ぶ

同期型とデバイス固定型のどちらが常に優れているとは限りません。

NIST SP 800-63B-4では、適切に実装された同期型認証器はAAL2で利用できますが、同期のために認証鍵を移動できる性質があるため、秘密鍵の非エクスポート性を求めるAAL3では使用できないと整理されています。

中小企業では、次のように業務上の重要度で使い分ける方法があります。

利用者・アカウント運用例
一般従業員会社が許可した同期先を使う同期型パスキー
複数の会社端末を使う営業担当者管理された同期型パスキーと端末管理を組み合わせる
システム管理者デバイス固定型のセキュリティキーを複数登録する
経理・送金承認者会社管理端末または専用セキュリティキーに限定する
緊急用管理者通常利用から分離したデバイス固定型認証器を安全に保管する
共有パソコンの利用者利用者ごとの個別アカウントと、各自の認証器を使用する
システム間連携用アカウントパスキーではなく、サービスが対応する証明書やワークロードID等を検討する

上表は、本稿における実務上の提案です。

使用するクラウドサービス、端末管理機能、法令・契約、情報の重要度に応じて調整してください。

パスキーの「引継ぎ」は認証情報を渡すことではない

担当者が異動・退職するとき、「後任者へパスキーを引き継ぐ」という表現を使うことがあります。

しかし、個人に発行したパスキーそのものを、後任者へ渡す運用は避けるべきです。

引き継ぐべきものは、次の内容です。

  • 担当業務
  • ファイル・メール・顧客情報
  • 承認権限
  • システム上の役割
  • 契約情報
  • 管理手順
  • 障害時の連絡先
  • サービスの所有者情報

引き継いではならないものは、次の内容です。

  • 前任者のアカウント
  • 前任者のパスキー
  • 前任者の端末PIN
  • 前任者の生体認証
  • 前任者用の予備コード
  • 前任者の個人クラウドアカウント
  • 前任者しか使えない管理者認証情報

NIST SP 800-63B-4は、認証器は利用者ごとに固有のものとし、利用者間で共有しないことを基本的な考え方としています。同期型パスキーには共有機能を備える実装もありますが、組織利用では、誰が操作したかを特定できなくなる危険を考慮する必要があります。

つまり、異動・退職時には、前任者のパスキーを後任者へ移すのではなく、後任者へ新しい個人別アカウントまたは新しい権限を発行します。

その後、前任者のアカウント、権限、登録パスキーを無効化します。

退職処理は「アカウント停止」と「パスキー削除」を分けて考える

退職者のパスキーだけを削除しても、そのアカウントに別の認証方法が残っていれば、退職者がサインインできる可能性があります。

反対に、アカウントを停止すれば、そのアカウントへ登録されたパスキーが残っていても、通常はサービスへサインインできなくなります。

そのため、退職時は次の順番で処理します。

段階実施内容
退職前業務、ファイル、メール、管理権限、承認権限を後任者へ移す
最終勤務時会社端末、セキュリティキー、ICカード等を回収する
退職時刻利用者アカウントを停止する
同時処理有効なセッション、アクセストークン等を失効させる
認証方法の整理登録済みパスキー、予備認証方法、回復先を削除する
権限確認グループ、共有フォルダ、クラウド、外部サービスの権限を削除する
証拠保存実施日時、実施者、確認者、処理結果を記録する

FIDO AllianceとHIDが2026年6月に公表した調査では、米国、カナダ、英国、フランス、ドイツのIT・サイバーセキュリティ意思決定者500人のうち、94％が退職者の物理・デジタルアクセスを24時間以内に無効化できると回答しました。

一方、35％は過去2年間に、実際の無効化で遅延または失敗を経験したと回答しています。この調査は日本企業を対象としたものではありませんが、「停止できると思っていること」と「実際に停止できること」は別である点を示しています。

パスキーを導入しても、退職者処理が自動的に改善されるわけではありません。

人事手続、アカウント管理、端末回収を連動させる必要があります。

パスキー導入時に決めたい八つの運用ルール

以下は、専任担当者がいない中小企業向けの実務上の提案です。

すべての企業に一律に課される法的義務ではありません。

1　重要なアカウントは一つの端末だけで運用しない

管理者アカウント、経理アカウント、代表メール、クラウド契約者アカウントなどは、一つのスマートフォンや一個のセキュリティキーだけに依存しないようにします。

少なくとも次のいずれかを準備します。

  • 二台目の会社管理端末へ別のパスキーを登録する
  • 主認証器とは別のセキュリティキーを登録する
  • 管理者が発行できる期限付きの復旧手段を用意する
  • 安全に保管した復旧コードを用意する
  • 本人確認を経て再登録できる手順を決める

NISTの同期型認証器に関する指針でも、AAL2以上の復旧を支える対策として、複数の認証器をアカウントへ登録することが挙げられています。

2　個人の同期アカウントを業務で使ってよいか決める

同期型パスキーを使う場合は、パスキーがどの認証情報管理サービスへ保存されるかを確認します。

会社として、次のいずれかを明文化します。

  • 会社が管理するアカウントだけを利用する
  • 個人アカウントへの業務用パスキー保存を禁止する
  • 一般サービスのみ個人アカウントを認める
  • 管理者・経理等の重要アカウントでは個人同期を禁止する
  • 例外利用には事前承認を必要とする

利用者が退職した後も、その個人アカウント側にパスキーが残る可能性を考える必要があります。

サービス側でアカウントとパスキーの関係を解除すれば、そのパスキーを使った認証は通常できなくなりますが、退職時にはアカウント停止と登録認証器の確認を両方行う方が確実です。

3　パスキーを登録できる人を決める

管理者アカウントへ、誰でも自由に新しいパスキーを追加できる状態は避けます。

特に重要なアカウントでは、次の内容を決めます。

  • 新規登録を申請できる人
  • 承認する人
  • 本人確認を行う人
  • 登録できる端末・セキュリティキー
  • 個人所有端末の可否
  • 登録後の通知先
  • 登録記録の保存場所
  • 不審な登録があった場合の連絡先

新しい認証器の登録は、ログイン後の単なる設定変更ではありません。

そのアカウントへ入るための新しい入口を追加する行為です。

4　復旧時の本人確認を事前に決める

利用者から「スマートフォンをなくしたので、パスキーを再発行してください」と連絡があった場合、メールや電話の申告だけで再発行してはいけません。

攻撃者が本人を装っている可能性があるためです。

本人確認方法として、次の組合せを決めます。

  • 上長または人事担当者による在籍確認
  • 会社がすでに管理している電話番号への折り返し
  • 対面確認
  • 社員証等の確認
  • 既存の別認証器による認証
  • 保存済みの復旧コード
  • 管理者が発行する期限付き認証情報
  • 既存の社内申請・承認経路
  • 重要アカウントでは二名による確認

復旧を依頼するメールに書かれた新しい電話番号や個人メールアドレスを、そのまま本人確認へ使ってはいけません。

会社が事前に登録していた連絡先や、人事情報と照合します。

5　端末紛失は「見つかるまで待つ」運用にしない

パスキーを保存した端末をなくした場合、利用者は探し続ける前に、会社へ第一報を行います。

紛失した認証器は、第三者が取得した可能性を前提に扱います。NIST SP 800-63B-4も、紛失、盗難、無断複製等のおそれがある認証器について、速やかに停止・無効化・破棄することを求めています。

第一報では、少なくとも次の内容を確認します。

確認項目内容
発覚日時紛失に気づいた日時
最終確認最後に端末を確認した場所と時刻
対象端末スマートフォン、パソコン、セキュリティキー等
所有区分会社所有、個人所有
端末保護PIN、生体認証、暗号化の有無
保存方式同期型、デバイス固定型
対象アカウントメール、クラウド、管理者画面等
管理機能MDM、遠隔ロック、遠隔消去の有無
予備手段別端末、予備キー、復旧コード等
現在の対応捜索、警察・施設への連絡等

6　管理者アカウントは通常利用から分ける

メール閲覧、ウェブ検索、日常業務で使うアカウントへ、会社全体を変更できる管理者権限を持たせると、事故時の影響が大きくなります。

一般利用アカウントと管理者アカウントを分け、管理者アカウントのパスキーは、会社管理端末または専用セキュリティキーへ登録します。

管理者用の予備認証器も用意しますが、通常の主認証器と同じかばん、同じ机、同じ担当者だけで管理すると、紛失、災害、長期不在に同時に影響されます。

主認証器と予備認証器は、管理者と保管場所を分けます。

7　復旧手段を主認証より弱くしすぎない

パスキーを導入しても、復旧時に「氏名と生年月日だけ」「メールだけ」「SMSだけ」で再設定できるなら、攻撃者はパスキーを正面から破る必要がありません。

弱い復旧手続を狙えばよいからです。

NIST SP 800-63B-4のAAL2向け復旧要件では、異なる方法で得た二つの復旧コード、復旧コードと既存の単要素認証器の組合せ、または本人確認の再実施などが示されています。これは米国連邦向けの技術基準であり、日本の中小企業に直接適用される法律ではありませんが、重要なアカウントを一つのメールや一つの電話番号だけで復旧させないという考え方は参考になります。

8　復旧できるか実際に試す

「予備キーを保管している」

「管理者が復旧できることになっている」

「端末をなくしてもクラウドから戻るはずだ」

書面上はそうなっていても、実際に試さなければ分かりません。

少なくとも重要アカウントについて、次の確認を行います。

  • 予備キーで実際にサインインできるか
  • 予備キーのPINを確認できるか
  • 同期型パスキーを別の会社端末で利用できるか
  • 管理者が認証器を無効化できるか
  • 期限付き復旧手段を発行できるか
  • 失効後に復旧手段が使用できなくなるか
  • 復旧操作がログへ残るか
  • 復旧時に通知が送られるか
  • 担当者不在でも手順書を見て対応できるか

本稿では、重要管理者アカウントは半年に一度、一般利用者向けの復旧手順は年に一度程度、机上確認またはテストアカウントで試す方法を提案します。

この頻度は法令上の一律義務ではありません。利用するサービス、業務停止時の影響、担当者の交代頻度に応じて決めてください。

端末を紛失したときの初動

端末紛失時は、端末側の対処と、サービス側の対処を分けます。

端末側で行うこと

  • MDM等から端末をロックする
  • 必要に応じて遠隔消去する
  • 端末の位置情報を確認する
  • SIMや通信契約を停止する
  • 会社アカウントから端末を切り離す
  • 端末証明書やVPN設定を失効させる
  • 警察や施設へ遺失物の届出を行う

サービス側で行うこと

  • 対象アカウントを一時停止する
  • 既存のサインインセッションを失効させる
  • 紛失端末に関連するパスキーを削除する
  • 不審なサインイン履歴を確認する
  • 新しい認証方法の登録履歴を確認する
  • メール転送や権限変更の有無を確認する
  • 予備認証器で本人を確認する
  • 新しい端末へ新しいパスキーを登録する

端末を遠隔消去したことと、クラウドサービス側でパスキーを無効化したことは、同じ処理ではありません。

MDM上の端末消去に成功しても、対象アカウントの有効なセッションや、別端末へ同期済みの認証情報が残っている可能性があります。

反対に、サービス側で対象パスキーを削除しても、端末自体に会社のデータや別サービスの認証情報が残っている可能性があります。

両方を確認します。

同期型パスキーの場合の復旧

同期型パスキーでは、紛失した端末以外の信頼できる端末で、同じパスキー管理サービスを利用できれば、別端末からサインインできる場合があります。

FIDO Allianceは、新しい端末で同じパスキー管理サービスを設定した場合、同期されたパスキーを利用できることがあると説明しています。また、別の端末にあるパスキーを使い、QRコード等を介してサインインするクロスデバイス認証も用意されています。

ただし、次の点を確認してください。

  • 別端末も本人または会社が管理する端末か
  • パスキー管理サービスのアカウントが侵害されていないか
  • 紛失端末の登録を同期サービスから削除したか
  • サービス側で紛失端末に関連するパスキーを確認したか
  • 個人アカウントへ同期されていないか
  • 新しい端末へ復旧した際に通知やログが残るか

同期されているから何もしなくてもよいわけではありません。

利用を継続できることと、紛失端末を安全に無効化できていることは別です。

デバイス固定型パスキーの場合の復旧

デバイス固定型パスキーは、端末やセキュリティキーから別の端末へ同期されません。

紛失・故障した場合は、次のいずれかで復旧します。

  1. 事前に登録していた二つ目のパスキーを使用する
  2. 別方式の予備認証器を使用する
  3. 保存済みの復旧コードを使用する
  4. 管理者が本人確認後に期限付き認証情報を発行する
  5. サービス所定の本人確認・アカウント回復を行う

重要なアカウントでデバイス固定型を採用する場合は、二本目のセキュリティキーを登録し、安全な別の場所へ保管する方法が考えられます。

予備キーを購入しただけでは不十分です。

対象アカウントへ実際に登録し、サインイン試験を行い、誰がどこで保管するかを記録します。

Microsoft Entra IDでは一時アクセスパスを復旧に使える

Microsoft Entra IDでは、パスキー等のパスワードレス認証方法を登録するための仕組みとして、一時アクセスパス、Temporary Access Passが用意されています。

一時アクセスパスは、利用時間を限定したパスコードで、一回限りまたは複数回使用できるよう設定できます。利用者は一時アクセスパスでサインインし、新しいパスキー等を登録できます。強力な認証方法を紛失した場合の回復にも利用できます。

ただし、「管理者が電話でコードを伝えれば復旧できる」という運用にしてはいけません。

一時アクセスパスを使う場合も、次の内容を決めます。

  • 発行前に誰が本人確認を行うか
  • 発行を承認できる管理者は誰か
  • 有効期間を何分・何時間にするか
  • 一回限りと複数回利用をどう使い分けるか
  • どの連絡手段で本人へ渡すか
  • 発行後に誰がログを確認するか
  • 新しいパスキーの登録完了を誰が確認するか
  • 不要になった一時アクセスパスを誰が削除するか
  • 復旧後に既存セッションを確認するか
  • 紛失したパスキーを誰が削除するか

一時アクセスパスは、本人確認の代わりではありません。

本人確認を行った後に、新しい認証方法を登録するための一時的な手段です。

2026年9月1日までにMicrosoft 365利用企業が確認したいこと

Microsoftの公表予定どおりであれば、この記事の公開日である2026年8月21日の11日後、9月1日から、SMSまたは音声認証の対象利用者に対してパスキーが自動的に有効化され、登録を促す仕組みが始まります。

Microsoft 365を利用している会社では、少なくとも次の事項を確認します。

確認項目確認内容
SMS・音声利用者現在、誰がSMS・音声認証を使っているか
パスキー対象者誰からパスキーへ移行するか
対応端末Windows、iPhone、Android等の利用状況
保存方式同期型とデバイス固定型のどちらを認めるか
個人端末業務用パスキーの登録を認めるか
管理者管理者用のパスキーと予備認証器があるか
一時アクセスパスポリシー、発行権限、有効期間を設定したか
利用者周知登録手順、紛失時連絡先を案内したか
ヘルプデスク登録できない利用者への対応を決めたか
退職処理アカウント・パスキー削除を手順へ追加したか

9月1日の変更では、対象利用者にパスキー登録が促されますが、Microsoftの公式文書では、当初は登録画面を延期できる設定になっています。

そのため、「9月1日に全員が突然サインインできなくなる」と説明するのは正確ではありません。一方、2027年2月1日以降は、SMSまたは音声しか使えない利用者に、スキップできないパスキー登録が求められる予定です。

早い段階で少人数の試行グループを作り、登録、端末交換、紛失、退職、管理者復旧まで確認することが重要です。

予備手段は「多ければよい」わけではない

認証手段を増やすほど、利用者が締め出される危険は下がります。

一方で、不要な予備手段を多数残すと、攻撃者が利用できる入口も増えます。

予備手段は、次の基準で選びます。

予備手段利点主な注意点
二つ目の同期型パスキー別端末から利用しやすい同期先アカウントの管理が必要
二つ目のセキュリティキー主端末と独立できる紛失、保管、PIN忘れへの対策が必要
期限付き一時認証情報必要なときだけ発行できる発行前の本人確認と権限管理が必要
保存型復旧コードオフライン保管できるコピー、紛失、利用後の更新が必要
別方式の認証器同じ障害の影響を受けにくい弱い方式を恒久的に残さない
対面本人確認高い確度で確認できる夜間・遠隔勤務では利用しにくい

NIST SP 800-63B-4では、保存型の復旧コードについて、オフラインで安全に保管し、使用後は無効化して新しいコードを発行する考え方が示されています。

復旧コードを保存する場合は、次のような運用を避けます。

  • パスキーを保存した端末の写真フォルダに保存する
  • 本人のメールボックスへ平文で送る
  • 社内共有フォルダへ誰でも見られる状態で置く
  • 印刷したコードを机の上に置く
  • 管理者全員が同じ復旧コードを共有する
  • 一度使用したコードをそのまま再利用する

重要アカウントの復旧コードは、アクセスできる人を限定した金庫、封印した保管袋、アクセス制限付きの機密情報保管場所などで管理します。

緊急用管理者アカウントを準備する

通常の管理者が利用できない場合に備えて、緊急用管理者アカウントを用意する方法があります。

緊急用管理者は、日常業務では使用しません。

次の条件を設けます。

  • 通常の管理者アカウントと分離する
  • 日常メールやウェブ閲覧に使用しない
  • 専用のデバイス固定型認証器を登録する
  • 主認証器とは異なる場所に予備認証器を保管する
  • 使用できる人を二名以上決める
  • 使用時は経営者等の承認を必要とする
  • サインイン時に通知する
  • 使用後はログを確認する
  • 認証器、PIN、保管状況を定期確認する
  • 半年ごとなど、決めた頻度でサインイン試験を行う

一人の担当者だけが、緊急用アカウント、認証器、PIN、手順書をすべて管理すると、その担当者の不在時に機能しません。

一方、誰でも使える場所へ置けば、緊急用アカウント自体が危険な入口になります。

「一人だけに依存しないが、無断では使用できない」管理にします。

パスキー管理台帳を作る

パスキーそのものの秘密鍵を会社の台帳へ記録する必要はありません。

記録すべきなのは、誰が、どのアカウントへ、どの種類の認証器を登録しているかです。

パスキー管理台帳の記載例

項目記録内容
サービス名Microsoft 365、会計、クラウド等
アカウント利用者ID、管理者ID
利用者・所有者誰に割り当てられたアカウントか
業務区分一般、経理、管理者、緊急用等
パスキー種別同期型、デバイス固定型
保存先会社端末、セキュリティキー、管理サービス等
会社管理会社が端末・同期先を管理できるか
登録日パスキーを登録した日
主・予備主認証器か予備認証器か
予備手段二つ目のパスキー、復旧コード、TAP等
紛失時連絡先第一報を受ける担当者
最終確認日最後に利用・設定を確認した日
復旧試験日最後に復旧手順を試した日
状態利用中、停止、紛失、削除済み等
削除日無効化・削除を行った日
確認者登録・削除を確認した人

台帳には、次の情報を記録してはいけません。

  • 生体情報
  • 端末のPIN
  • セキュリティキーのPIN
  • パスキーの秘密鍵
  • 復旧コードの平文
  • 個人クラウドアカウントのパスワード

復旧コードを保管する必要がある場合は、台帳には保管場所と管理者だけを記録し、コード本体は別の安全な場所へ保管します。

月1回確認したいパスキー管理の数字

本稿では、月次の差分確認と、半年または年1回の全体確認を組み合わせる方法を提案します。

指標確認する意味目指す状態
パスキー登録率導入対象者が登録できているか対象者と一致
一つの認証器しかない重要アカウント数紛失時に締め出されないか0
個人同期先を使う重要アカウント数会社が管理できない保存先がないか原則0
所有者不明のパスキー数誰の認証器か分からないものがないか0
退職・異動後に残る認証器数無効化漏れがないか0
紛失・故障中の認証器数未処理の事故がないか0
復旧試験期限超過数手順が形骸化していないか0
緊急管理者の未確認数緊急時に利用できるか0
復旧コードの所在不明数予備手段を管理できているか0
不審な認証器追加件数アカウント侵害がないかすべて確認

パスキー登録率を100％にすることだけを目標にしてはいけません。

重要なのは、登録後に、紛失、交換、異動、退職、管理者不在へ対応できることです。

端末紛失を想定した机上訓練

次のような状況を設定します。

金曜日の午後8時、経理責任者から「会社支給のスマートフォンを帰宅途中に紛失した」と連絡が入った。スマートフォンには、Microsoft 365、インターネットバンキング、請求書サービスのパスキーが登録されている。翌営業日の午前中に支払処理が必要である。

この状況で、次の質問へ答えられるかを確認します。

  1. 最初に誰へ連絡するか
  2. 夜間に連絡できる管理者は誰か
  3. 端末を遠隔ロックできるか
  4. 対象となるパスキーを一覧にできるか
  5. 既存セッションを失効できるか
  6. インターネットバンキング側でも認証器を削除できるか
  7. 経理責任者本人をどのように確認するか
  8. 予備のパスキーまたはセキュリティキーがあるか
  9. 翌営業日の支払業務を誰が代行するか
  10. 実施した対応をどこへ記録するか

答えられない項目があれば、それが運用上の不足です。

実際の端末を紛失させる必要はありません。テストアカウントや手順書を使った机上確認でも、連絡先不明、予備キー未登録、管理者権限不足などを発見できます。

30日でパスキー運用を整える

期間実施すること完成させるもの
第1週パスキー対応サービス、利用者、端末を洗い出す対象サービス一覧
第1週同期型・デバイス固定型、個人端末利用の方針を決めるパスキー利用方針
第2週一般利用者、管理者、経理、緊急用を分類するアカウント区分表
第2週重要アカウントへ予備認証器を登録するパスキー管理台帳
第3週紛失時の本人確認、停止、再登録手順を作る紛失・復旧手順
第3週退職・異動手順へパスキー削除を追加する退職時チェック表
第4週テストアカウントで端末紛失を想定する復旧試験記録
第4週利用者へ登録方法と連絡先を周知する利用者向け一枚資料

最初から全社員を一斉に切り替える必要はありません。

次のような少人数の試行グループから始めます。

  • 情報システムまたは総務担当者
  • 複数種類の端末を使う人
  • 在宅勤務者
  • 管理者権限を持つ人
  • スマートフォンを業務利用する人
  • ITに詳しくない人

ITに詳しい利用者だけで試すと、実際の全社展開時に起こる問題を見落とします。

端末交換、PIN忘れ、個人端末利用、管理者不在など、異なる状況を含む利用者で確認します。

経営者が確認したい五つの質問

経営者がWebAuthnや公開鍵暗号の詳細を理解する必要はありません。

担当者へ、次の五つを質問してください。

  1. 重要なアカウントで、パスキーを保存した端末を失っても復旧できるか
  2. 業務用パスキーが個人のクラウドアカウントへ保存されていないか
  3. 退職・異動時に、アカウントと登録パスキーを両方確認しているか
  4. 通常の管理者が不在でも、緊急用管理者で復旧できるか
  5. 最後に端末紛失を想定した復旧確認を行ったのはいつか

この五つに答えられないからといって、直ちにアカウントが危険な状態だと断定することはできません。

しかし、パスキーを「登録しただけ」で、会社として管理できていない可能性があります。

まとめ

パスキーは、パスワードの使い回しや、認証情報を偽サイトへ入力させるフィッシング攻撃を減らす有効な仕組みです。

一方で、パスキーはアカウント管理そのものを不要にする技術ではありません。

会社として決めるべきなのは、次の事項です。

  1. 同期型とデバイス固定型をどう使い分けるか
  2. 個人の同期アカウントを業務で認めるか
  3. 重要アカウントへ予備認証器を登録するか
  4. 端末紛失時に誰が何を停止するか
  5. 復旧時に本人をどう確認するか
  6. 異動・退職時に何を後任者へ移すか
  7. 前任者のアカウントとパスキーをいつ削除するか
  8. 管理者不在時に誰が会社を復旧させるか

パスキーの「引継ぎ」とは、前任者の認証器を後任者へ渡すことではありません。

業務、データ、役割、権限を後任者へ移し、後任者には新しい認証情報を発行することです。

最初の一歩として、Microsoft 365、Google Workspace、会計、銀行、サーバー管理など、会社にとって重要な五つのサービスを選んでください。

そして、それぞれについて次の一文を完成させます。

このパスキーを保存した端末を今日失った場合、誰が、何を使い、どの手順で業務を再開するか。

この一文へ具体的に答えられれば、パスキーは単なる新機能ではなく、会社が管理できる認証手段になります。

ライトハウスコンサルタントでは、専任の情報システム担当者がいない中小企業を対象として、アカウント、管理者権限、多要素認証、退職時処理、端末紛失時の初動を含む情報セキュリティ管理の整理を支援しています。

パスキーを導入したものの、予備手段がない、個人端末との区別が分からない、管理者が一人しかいないという場合は、製品を追加する前に、現在のアカウントと復旧方法を一覧にすることが重要です。

投稿タグ
, , , , , , , , ,