>
>
公開日
多要素認証を導入した後も、SSO非対応のSaaSやローカル管理者、共有アカウントには適用漏れが残り得ます。情報システム部門向けに、利用者・管理者別の適用状況を整理する一覧表と、フィッシング耐性を踏まえた見直しの判断軸を解説。公的資料の手法例示と現行の義務の違いも整理します。
多要素認証とは
多要素認証（MFA）とは、異なる種類の認証要素を組み合わせて本人を確かめる仕組みです。
本記事のポイント
導入済みでも適用漏れは残ります
利用者と管理者は分けて点検します
認証方式によってフィッシング耐性は異なります
クラウドサービスごとの一覧が点検の起点です
対象読者は、企業の情報システム部門の担当者・管理者です。二要素認証の設定があることと、必要なアカウントで実際に使われていることを分けて捉え、点検につなげます。情報の基準日は2026年10月22日時点です。一覧・点検の順序・役割分担は編集部の提案です。
認証要素は、パスワードなど本人が知っている「知識」、本人が持つ端末などの「所持」、指紋や顔の特徴などの「生体」に分けます。二要素認証は、このうち異なる2種類を組み合わせる認証です。一方、二段階認証は認証を段階に分けることを指し、同じ種類の要素を使う場合もあります。入力が二段階でも、二要素認証とは限りません。
2026年10月には、IPA、国家サイバー統括室、総務省が相次いで認証機能の強化を求めました。個人情報保護委員会は10月7日の注意喚起「大規模な漏えい等事案を踏まえた対応について」の別紙で、ガイドラインの手法の例示の見直し予定内容（確定は2027年4月の予定）を先取りして示し、組織外ネットワークからのアクセス、管理者権限でのアクセス、重要な個人データへのアクセスに、フィッシング耐性のあるものを含む多要素認証の導入を挙げています。
運用を見直すなら、クラウドサービスごとに「利用者への適用」「管理者への適用」「認証方式」を並べます。適用を確認できないアカウントがあれば、導入済みとして扱わず、点検対象に残します。
公的資料が求める認証強化と位置付け
2026年10月の注意喚起で認証強化に触れているのは、次の4機関です。いずれも事業者に対策を求める要請や、見直し予定の手法の例示で、それだけで法令上の義務になるものではありません。
IPA・国家サイバー統括室・総務省の要請
IPAは2026年10月9日の「不正アクセスによる漏えい等の事案を踏まえ、速やかに実施すべき対策等について」で、自組織が利用している外部サービスの対策として「認証機能（多要素認証・パスワード）の強化」「アカウント付与の範囲見直し」「アカウント棚卸の運用見直し」を挙げています（推奨）。
同日、国家サイバー統括室は「不正アクセスによる漏えい等の事案を踏まえた対応について」で、多要素認証の導入、推測されやすいパスワードの禁止、管理者アカウントの利用者とアクセス権の最小化を求めました（推奨）。総務省は同じ内容を、所管事業者と関係団体に注意喚起しています。
個人情報保護委員会の先取り公表
個人情報保護委員会は、2026年9月16日の委員会で「手法の例示」等の見直しを決め、10月7日の注意喚起で見直し予定の内容を先取りして公表しました。確定は2027年4月の予定です。別紙は、組織外ネットワークからのアクセス、管理者権限でのアクセス、重要な個人データへのアクセスについて、識別・認証手法を複数組み合わせる、フィッシング耐性のあるものを含む多要素認証の導入を挙げています。
現行の義務との関係
民間事業者の現行の義務は、個人情報保護法第23条の安全管理措置です。ガイドライン（通則編）10-6が「講じなければならない措置」とするのは、（1）アクセス制御、（2）アクセス者の識別と認証、（3）外部からの不正アクセス等の防止、（4）情報システムの使用に伴う漏えい等の防止の4つです。現行の（2）の手法の例示（ユーザーID、パスワード、磁気・ICカード等）に、多要素認証は含まれていません。委員会は「手法の例示」について、例示の全てを講じなければ法違反になるものではないと説明しています。
IdPの外にあるアカウントと認証の適用範囲
IdP側の設定だけでは、連携していないアカウントの保護状況は判断できません。IdPとは、認証情報や認証処理を担う基盤です。複数サービスへのサインインをまとめるSSOでは、IdPが認証を担います。一方、多要素認証（MFA）は本人確認を強化する仕組みであり、SSOとは役割が異なります。詳しくはSSOの仕組みと導入時の考え方に譲り、ここでは認証の適用範囲を整理します。
点検では、SSOとの連携の有無、サービス独自の認証、端末のローカル認証、複数人によるアカウント利用を分けて扱います。これらをすべて同じ設定で保護できると考えず、アカウントとログイン経路の組み合わせを点検対象にします。
SSO非対応のSaaSと直接ログイン
SSO非対応のSaaSと、SSOを経由しない直接ログイン経路は、別々の点検対象です。SaaSはインターネット経由で利用するソフトウェアサービスを指し、連携の有無だけで認証の保護状況を判定しないようにします。
編集部の提案は、利用中のサービスについて、次の条件に応じて点検対象を追加します。サービス名だけでなく、どのアカウントがどの経路を使うかまで記録すれば、設定を調べる場所を切り分けられます。
条件 | 点検対象と判断 |
|---|---|
SSOに対応していない場合 | サービス側の認証設定を対象にし、MFAの設定状況を記録します。 |
SSO連携済みでも直接ログイン経路がある場合 | その経路も一覧に追加し、サービス独自の認証設定を別に点検します。 |
設定状況を把握できない場合 | 保護済みと扱わず、未確認として担当者と確認先を記録します。 |
SSO連携サービスの一覧だけで、全アカウントの適用率を算出してはいけません。対象から外れたアカウントや未確認の経路が残っているなら、確認できた範囲を明記し、全体への適用状況とは区別します。
ローカル管理者と共有アカウント
端末内で認証するローカル管理者と、複数人が使う共有アカウントは、認証の場所と利用者の管理を分けて点検します。ローカル管理者とは、端末内に管理者権限を持つアカウントです。SSO側の設定を、そのまま端末のローカル認証の設定として扱わないようにします。
端末の管理画面や管理台帳からローカル管理者を把握できるなら、対象端末、アカウント、認証設定の管理担当を一覧に加えます。把握できない場合は、端末管理担当による洗い出しを先行させ、点検済みの対象には含めません。
共有アカウントは、複数人で利用するという運用上の論点です。利用者が特定できないなら、MFA設定の変更より先に、利用者と管理責任者を整理します。利用者を整理できた場合は、認証手段を誰が管理し、担当変更時に誰が引き継ぐかまで点検項目に加えます。
経済産業省は、「情報セキュリティ管理基準」のアクセス権管理に識別情報の管理、認証情報、アクセス権を含めており、本記事ではMFA設定の根拠ではなく、アカウントを洗い出す観点として参照します。洗い出したアカウントに管理者権限の有無を記録できれば、その一覧を使って次の権限別の点検に進めます。
▲ SSO連携状況やログイン経路に応じた点検対象の判断手順。
管理者アカウントの適用漏れと権限別の点検
一般利用者への適用状況だけでは、管理者アカウントの保護状況は判断できません。サービス単位の「導入済み」という表示ではなく、権限別・アカウント別に設定状況を分けて点検します。
利用者と管理者の設定差
利用者向けの設定が有効でも、管理者側の適用を確認できなければ、管理者アカウントを適用済みに含めません。
国家サイバー統括室は、管理者アカウントの利用者とアクセス権を必要最小限にするよう求めています。個人情報保護委員会のWARNING（2026年10月7日改訂）も、事例の対策例として「管理者権限等の不正利用された際の被害が大きいアカウント」に多要素認証等の高い強度の認証方式を採用することを挙げています。管理者アカウントは、利用者の設定とは別に1つずつ確かめます。
管理者アカウントごとの点検対象
管理者側の点検では、アカウントごとに権限、認証経路、適用状態、担当者を対応付けます。編集部の提案として、次の区分に該当するアカウントが存在する場合は、利用者の一覧に埋め込まず、アカウント単位で別行に整理します。
整理する区分 | 行ごとに記録する内容 |
|---|---|
管理権限を持つアカウント | 保有する権限、扱う情報、認証経路、適用状態 |
管理専用アカウント | 利用目的、担当者、認証経路、適用状態 |
例外として残したアカウント | 例外の理由、責任者、適用状態、見直し予定 |
適用状態は「適用済み」「未適用」「未把握」に分けて記録します。設定画面の表示だけで一括判定せず、対象アカウントと認証経路に対応する設定を根拠として残します。
未適用と分かっている場合は、管理者側の是正を先行させます。
設定状況を把握できない場合は、担当者と認証経路の特定を先行させ、是正対象を確定します。
点検・是正の優先順位は、権限の強さと扱う情報の性質・量を軸に決めます。企業規模による一律の基準は設けず、情報の閲覧範囲や設定変更権限を各行に記録すれば、対応順の理由を説明できます。
フィッシング耐性を踏まえた認証方式の比較
MFAが有効でも、その方式がフィッシング耐性を備えているとは限りません。多要素認証の適用範囲と、偽の認証画面などを使う攻撃への耐性は、別の軸で判断します。適用漏れがなくても、採用している方式によって残るリスクは異なります。
コード・通知型の注意点
コードの入力や通知の承認を追加していても、それだけでフィッシング耐性があるとは判断できません。
米国国立標準技術研究所（NIST）の認証ガイドラインSP 800-63B-4は、OTPや帯域外認証のように認証器の出力を手入力する方式を、出力が認証中のセッションに結び付かないため、フィッシング耐性があるとはみなさないと定めています。メールは帯域外認証に使うこと自体を認めていません。フィッシング耐性のある方式の例としては、認証先のドメインに結び付けて認証するWebAuthn（FIDO2）を挙げています。
方式 | フィッシング耐性に関する資料上の位置付け | 点検する認証経路 |
|---|---|---|
SMS認証 | NISTはフィッシング耐性ありとみなさない（手入力型の帯域外認証） | 通常ログインと、SMSへ切り替える代替経路を点検します |
メールコード | NISTは帯域外認証へのメールの利用を認めていない | 通常ログインと、メールを使う復旧経路を点検します |
認証アプリによるOTP | NISTはフィッシング耐性ありとみなさない（手入力するOTP） | ワンタイムパスワードの入力経路と、端末変更時の経路を点検します |
プッシュ通知 | NISTがフィッシング耐性の例に挙げる方式（認証先への結び付け）には当たらない | 通知による承認経路と、承認できない場合の代替経路を点検します |
パスキー | FIDO Allianceはパスキーをフィッシング耐性のある認証として説明。NISTもWebAuthnを耐性の例に挙げる | 対象の実装で使う経路と、別方式へ切り替わる経路を点検します |
表は認証手段の比較であり、各行が単独でMFAとして成立することを意味しません。手段の名称と、MFAとしての構成は分けて整理します。
フィッシング耐性を踏まえた選定軸
利用できる方式と代替経路まで整理できれば限定検証へ進み、すぐに移行できなければ既存MFAの適用漏れ解消を先行させます。
Oktaの調査「Secure Sign-in Trends Report 2025」によると、同社のWorkforce Identity顧客で、フィッシング耐性のある認証器（FastPass、WebAuthn、スマートカード）の採用率は1年で8.6％から14.0％に上がりました（2025年1月時点、日本語の発表）。同社の顧客での数値で、日本企業全体の導入率ではありません。
方式を見直す際は、次の順で判断します。
利用中の方式と、代替・復旧時に通る認証経路を一覧にします。
フィッシング耐性を備えた方式を利用できる場合は、対象者を限定し、通常利用と復旧操作を検証します。
すぐに移行できない場合は、既存MFAの適用漏れを解消し、方式変更は別の課題として管理します。
「全対象でMFAが有効」という結果が出ても、方式の見直しが完了したとは扱わず、残る認証経路を次の点検対象にします。
▲ 認証方式におけるフィッシング耐性の位置付けと点検経路の比較。
クラウドサービス別の適用状況一覧と点検順序
重要な情報を扱うクラウドサービスごとに、利用者と管理者のMFA適用状況を分けて一覧にします。
以下の一覧は、MFAの適用漏れを洗い出すための管理例です。公的資料による指定書式ではありません。サービス単位で「導入済み」とまとめず、アカウント区分と認証経路ごとに記録し、是正する対象と担当者を決めます。
適用状況一覧の記入項目
一覧では、利用者と管理者を別行にし、MFAの設定があるかではなく、対象アカウントに適用されているかを記録します。
サービス名 | 扱う情報 | アカウント区分 | 認証経路 | SSO連携 | MFA適用状況 | 認証方式 | 管理責任者 | 次の対応 |
|---|---|---|---|---|---|---|---|---|
利用者 | ||||||||
管理者 |
サービスごとに上の空欄を複製して使います。認証経路はログイン時に通る入口や認証先、SSO連携は複数サービスへのログインをまとめる仕組みとの接続状況を記入する欄です。同じ利用者区分でも、SSO経由とサービスへの直接ログインがある場合は行を分けます。たとえば（仮の記入例）、会計SaaSのSSO経由の利用者行は「適用済み」、直接ログインの行はサービスの認証設定画面で適用対象を確認できていないため「未把握」とし、次の対応に「サービス管理者へ直接ログイン用のMFA設定画面の確認を依頼」と記入します。確認後に適用が裏付けられれば「適用済み」へ、未適用と分かれば管理責任者を決めて是正対象へ移します。共有アカウントやSSO外のアカウントも対象に含め、共有の場合はアカウント区分にその旨を追記します。
この一覧での「適用済み」は、対象アカウントと認証経路への適用を確認できた状態です。適用されていないと確認できれば「未適用」、確認材料が足りなければ「未把握」と記録します。設定画面にMFAの項目があるだけで「適用済み」にするのは避けます。一部のアカウントだけ適用されている場合も、行を分けて記録してください。分けなければ、未適用の対象を次の対応につなげられません。
確認中の段階では状態を空欄にせず「未把握」とし、「次の対応」に不足する確認材料を残します。管理責任者には、設定変更や関係部門への依頼を進める担当を記入し、確認作業の引き取り先を明確にします。
初回点検から是正までの順序
初回点検では対象と権限を整理してから一覧を埋め、未適用と未把握を分けて対応先を決めます。
対象サービスと権限の整理：扱う情報を記入し、利用者・管理者・共有アカウントを洗い出します。洗い出しでは、ID棚卸し結果、SaaS管理台帳、端末管理の資産情報、特権ID管理の記録のうち手元にあるものと突き合わせ、外部委託先が管理するアカウントや複数テナントのアカウントは別行にします。管理権限を持つアカウントが利用者側に混ざっていれば、管理者の行へ分けます。
設定情報による記入：設定画面や取得可能な設定情報をもとに、認証経路、SSO連携、適用対象、認証方式を埋めます。対象への適用を裏付けられなければ「未把握」とし、推測で「適用済み」に変えません。
是正対象と次の作業の決定：下表の判断に沿って、設定変更に進む対象と、経路や適用範囲の調査を続ける対象を分けます。管理責任者と次の対応をセットで記録します。
変更後の再点検：是正した場合や、権限・認証経路・認証方式を変更した場合は、変更した対象を再点検します。適用を確認できれば一覧を更新し、確認できなければ未把握として調査を継続します。
判断欄 | 結果に応じた次の作業 |
|---|---|
管理者の未適用が判明 | 管理者側の適用漏れを優先的な是正対象とし、設定変更と変更後のログイン確認を計画します。 |
認証経路が不明 | 経路の特定を先に進めます。経路が分かれば適用判定へ進み、分からなければ未把握のまま調査担当を割り当てます。 |
適用は確認済みで、方式だけが課題 | 適用漏れの是正とは分け、方式変更の検証へ進みます。対象アカウントで変更後もログインできるかを確認します。 |
一覧には、変更後の確認結果も記録します。これにより、是正済みの対象と調査中の対象を区別できます。適用範囲の整理を終えた対象は、権限別の点検や認証方式の検討につなげます。
▲ 初回点検から是正・再点検までの点検順序。
認証だけに依存しない対策と管理体制
MFAを有効化しても、脆弱性対応や権限管理は別途続ける必要があります。設定変更と点検結果を引き継げるよう、担当範囲を決めておきます。
脆弱性対応との組み合わせ
多要素認証の設定状況と脆弱性への対応状況は、別々に完了を判断します。認証を強化したことを理由に、更新や修正の対応まで完了扱いにはしません。
個人情報保護委員会は、WARNING「不正アクセスによる個人データ漏えい防止のための注意喚起」（2026年10月7日改訂）で、対策を単一ではなく多層的に講じ、取り扱う個人データの性質と量に応じて、多要素認証などの高い強度の認証方式を採用する方針を示しています。認証方式の選定と、利用するシステムの脆弱性への対応を組み合わせる考え方です。
点検で未対応の脆弱性が見つかった場合は、認証設定の記録とは分けて、対応担当者・対応期限・完了を判断する根拠を残します。修正をすぐに適用できない場合は、暫定対応と再判断の期限も記録します。「認証を強化したので対策は完了」と処理しないことが、管理上の区切りになります。
点検結果を引き継ぐ責任分担
複数の担当者がアカウント管理に関わる場合は、一覧の管理、設定の把握、変更情報の連携を分担します。
担当 | 担う役割 |
|---|---|
情シス部門 | 一覧の管理を担い、未確認項目と対応状況を整理します。 |
サービス管理者 | 設定状況を把握し、確認結果と確認日を一覧へ反映します。 |
権限変更に関わる担当者 | 変更対象のアカウントと変更内容を関係者へ連携します。 |
設定情報を一覧に取り込む際は、取得方法に応じて次のように扱います。
自動取得できる設定情報がある場合は、取得対象の項目とアカウントの範囲を明らかにし、取得日時とともに一覧へ反映します。
取得できない項目は、サービス管理者による確認で補います。確認が終わるまでは未確認として残し、担当者と確認予定を記録します。
自動化の有無と、確認済みの範囲は別の情報です。ツールが情報を取得できても、その取得対象外まで確認済みにはしません。引き継ぎ時には「確認対象・確認日・未解決事項・次の担当者」を記録すれば、後任がどこから対応を再開するか判断できます。
変更の連絡を受けた場合は、サービス管理者が変更後の設定を確かめ、情シス部門が一覧への反映を管理します。製品の導入を完了条件にせず、記録と実際の設定が一致した範囲をもって点検を完了します。
まとめ
多要素認証の点検は、次の3点で進めます。
重要な情報を扱うクラウドサービスごとに、利用者と管理者の多要素認証の適用状況を「適用済み・未適用・未把握」で一覧にします。
IdPの外にあるアカウント（SSO非対応のSaaS、ローカル管理者、共有アカウント）と管理者アカウントは、別の行で1つずつ確かめます。
適用範囲とは別に、認証方式のフィッシング耐性と、SMSやメールに切り替わる代替・復旧経路を点検します。
2026年10月にはIPA・国家サイバー統括室・総務省が認証機能の強化を求め、個人情報保護委員会はフィッシング耐性のある多要素認証を、見直し後の手法の例示として先取りで示しました（確定は2027年4月の予定）。
まとめ
導入後の点検では、適用範囲と認証方式を分けて把握します。
多要素認証の点検対象には、IdPで管理するアカウントだけでなく、IdP外のアカウントも含めます。利用者と管理者を分けて整理したうえで、認証方式はフィッシング耐性を踏まえて見直す方針です。
最初の一歩は、重要な情報を扱うクラウドサービスを選び、利用者と管理者の適用状況を同じ一覧に記入することです。記入欄は「サービス名・権限区分・適用状況・認証方式」とし、導入済み環境の保護範囲を整理します。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
