MFAが勝手に変更・解除された時の初動対応チェックリスト

冒頭要約

身に覚えのない「MFAを追加しました」「2段階認証が解除されました」「回復用電話番号が変更されました」という通知は、設定ミスだけでなく、第三者がアカウントへの継続的な入口を作った兆候である可能性があります。一方、端末交換、管理者による正規リセット、古い認証方法の整理でも通知は発生します。

最初にやることは、通知内のリンクを押さず、公式アプリや保存済みブックマークから認証方法の一覧と変更履歴を確認することです。自分や承認済み管理者の操作でなければ、証跡を残しつつ、不審な認証方法、回復先、既存セッションを順に無効化します。

この記事では、個人、情シス、開発者、SaaS管理者が、通知の真偽確認、封じ込め、安全な再登録、記録、エスカレーションを進める手順を整理します。攻撃の再現方法ではなく、防御と復旧に必要な確認だけを扱います。

通知のボタンからログインしない

正規サービスの通知に見えても、メール、SMS、チャット内の「確認する」「変更を取り消す」は使いません。公式アプリ、普段のブックマーク、社内ポータルなど、通知とは別の経路から設定画面を開いてください。

MFA変更・解除通知とは

MFAは、パスワードとは別の認証要素を組み合わせる仕組みです。サービスによって「2段階認証」「2要素認証」「Security info」「ログイン方法」など表示名は異なりますが、通知の対象になりやすいイベントは共通しています。

認証アプリ、電話番号、セキュリティキー、パスキーの追加・削除。
既定の認証方法やバックアップ方法の変更。
回復用メール、回復用電話番号、信頼済み端末の変更。
リカバリーコードの再生成やアカウント回復の実行。
MFAポリシー、条件付きアクセス、管理者による認証方法リセット。

NIST SP 800-63Bは、新しい認証器の追加やアカウント回復などの重要イベントについて、処理とは独立した経路で利用者へ通知することを求めています。したがって通知が届くこと自体は正常な防御機能ですが、心当たりがない通知は、認証器が不正に追加・無効化された可能性を確認するための開始点として扱います。

「MFAの変更」と「不審なログイン」は同じ事象ではありません。第三者が既存セッションを利用して設定だけを変えた場合、新しいログインが直前に見つからないこともあります。身に覚えのないログイン通知の確認方法と合わせ、設定変更とサインインを別々に確認します。

読者別の影響

読者	まず確認すること	見落としやすい影響
個人利用者	現在登録されている認証方法、回復先、端末、最近のログイン	不明なパスキー、回復用メール、アプリパスワード、残存セッション
情シス・CSIRT	IdPの認証方法変更、実行者、対象、サインイン、管理者操作	本人申告だけで正規変更と判断すること、複数SaaSへの波及
開発者	GitHubやクラウドの2FA、パスキー、SSH鍵、トークン、セキュリティログ	CI/CD、組織、リポジトリ、クラウド権限への二次影響
SaaS管理者	管理者によるリセット、認証ポリシー、監査ログ、セッション失効範囲	IdP側を止めてもSaaS独自セッションが残ること

管理者、経理、人事、メール、GitHub、クラウド管理画面のアカウントでは、変更された認証方法が組織全体への入口になる可能性があります。本人がまだログインできる場合でも、通常の問い合わせではなくセキュリティ初動として記録します。

まず確認すること：15分チェックリスト

1. 通知と本人の操作を記録する

通知の受信日時、対象アカウント、件名、送信経路を記録する。
通知が示す変更日時、追加・削除された方法、端末名などを記録する。
本人が端末交換、電話番号変更、パスキー追加、MFA再登録を行ったか確認する。
会社アカウントでは、ヘルプデスクや管理者が正規のリセットを実施していないか確認する。
リンクを押した、認証情報を入力した、MFA要求を承認した場合は操作時刻も残す。

通知はすぐ削除せず、組織の報告・保全手順に従います。ただし、証跡取得のために封じ込めを長時間遅らせないでください。

2. 公式画面で現在の認証方法を確認する

認証アプリ、電話番号、セキュリティキー、パスキーの一覧。
既定または優先に設定されている認証方法。
回復用メール、回復用電話番号、バックアップコードの状態。
見覚えのない端末、ブラウザ、信頼済みデバイス。
追加日時、最終利用日時、表示名など、サービスが提供する補助情報。

通知に書かれた方法が現在の一覧にない場合でも、変更後に削除された可能性があります。通知、設定画面、監査ログの3つを照合します。

3. 何が変わったかを分類する

変更	確認する意味	優先して見ること
新しい認証方法の追加	第三者が継続アクセス用の方法を登録した可能性	種類、追加時刻、実行者、直前のセッション
既存MFAの削除・解除	パスワードだけで入れる状態になった可能性	現在の保護状態、解除者、ポリシー変更
回復先の変更	本人が回復できないようにされた可能性	旧・新回復先、アカウント回復イベント
リカバリーコード再生成	古いコードが失効し、新しいコードを第三者が保持した可能性	実行時刻、利用済みコード、他の設定変更
管理者によるリセット	正規サポートまたは管理者アカウント悪用の可能性	チケット、承認者、管理者監査ログ、本人確認記録

4. 最近のサインインとセッションを確認する

変更前後の成功・失敗・ブロックされたサインイン。
時刻、端末、ブラウザ、OS、利用アプリ、認証方法。
パスワードリセット、MFA要求、アカウント回復の通知。
現在有効なセッションと、見覚えのない接続端末。
VPN、モバイル回線、企業プロキシなど、場所表示がずれる要因。

場所だけで本人か第三者かを断定しません。時刻、端末、アプリ、認証方法、設定変更を一つの時系列に並べます。

5. 組織では監査ログで変更主体を確認する

Microsoft Entraでは、認証方法の登録・削除を含む変更は監査ログの対象です。Microsoftは特権アカウントに対する認証方法の変更を、高重要度で監視すべきイベントとして挙げています。製品ごとの画面名は変わるため、現時点で公開されている公式情報を確認しながら、少なくとも次を特定します。

対象ユーザー、変更した主体、変更結果、発生時刻。
管理者操作、セルフサービス操作、自動処理のどれか。
変更元のIPアドレス、端末、相関IDなど、提供される調査情報。
同じ主体による他ユーザーの変更、権限付与、アプリ同意。
変更前後のサインイン、リスク検知、ポリシー変更。

GitHubではセキュリティログの2FA関連イベントを、Google Workspaceではユーザーレポートや監査・調査機能を確認します。利用できるログ項目と保持期間は契約や製品設定で異なるため、確認できない場合も「ログなし」と記録します。

6. 変更後の操作を確認する

メール転送、受信トレイルール、委任設定。
OAuthアプリ、SaaS連携、アプリパスワード。
管理者権限、グループ、外部共有、ゲストユーザー。
GitHubのトークン、SSH鍵、リポジトリ、Actionsシークレット。
クラウドのAPIキー、アクセスキー、サービスアカウント。

認証方法の変更が入口で、目的がメール、ファイル、コード、クラウド権限の利用である可能性があります。SaaS権限棚卸しチェックリストを使い、認証設定だけで調査を終えないようにします。

初動対応：やること

心当たりがあり、正規変更と確認できた場合

変更日時、変更理由、本人または承認者を記録する。
古い認証方法や不要な回復先が残っていないか確認する。
バックアップ方法が一つもない状態を避ける。
高権限アカウントでは、変更チケットと監査ログをひも付ける。

「本人がやったと思う」だけでなく、本人の操作時刻、端末、変更内容がログと一致することを確認します。

心当たりがなく、まだログインできる場合

信頼できる端末から公式画面を開き、変更イベントを記録する。
不審な認証方法、回復先、端末を無効化する。
見覚えのないセッションを失効し、必要なら全セッションを終了する。
パスワードを変更し、同じパスワードを使う他サービスも個別に変更する。
本人確認後、安全な認証方法を再登録する。
OAuth、メール設定、権限、トークン、操作ログを確認する。
会社アカウントは情シス・CSIRTへ報告し、IdPと対象SaaSのログを保全する。

Microsoft Entraの公式説明では、IdP側でトークンを失効しても、アプリが独自に発行したセッションはアプリ側の制御下にある場合があります。そのため、IdPのセッション失効と各重要SaaSのセッション確認を分けて実施します。Session Revocationの考え方も確認してください。

ログインできない、回復先も変わっている場合

通知内リンクではなく、公式サイトのアカウント回復窓口を使う。
会社アカウントは、社内ポータルに掲載されたヘルプデスクへ別経路で連絡する。
MFAコード、リカバリーコード、パスワードをメールやチャットで共有しない。
ヘルプデスクは、電話番号や社員番号の申告だけでMFAを再登録しない。
復旧後に、認証方法、回復先、セッション、連携アプリ、操作履歴を再確認する。

本人確認を受け付ける側は、ヘルプデスクを狙うMFAリセット依頼の初動対応を使い、依頼者と承認経路を分離します。

やってはいけないこと

通知メールやSMSのリンクからログインしない。
不審な認証方法を調査目的で使ってみない。
本人確認をせずにMFAを解除・再登録しない。
パスワード変更だけで対応完了にしない。
IdPのセッション失効だけで全SaaSからログアウトしたと考えない。
証跡保全だけを優先し、侵害中のアカウントを長時間使えるままにしない。
回復用電話番号やメールを一つだけに依存しない。
不審な通知や監査ログを、対応完了前に削除しない。

端末自体の侵害が疑われる場合は、その端末から新しいパスワードやMFAを登録しないでください。情シス・CSIRTと連携し、信頼できる別端末から封じ込めを進めます。

記録すべきこと：初動メモテンプレート

対象アカウント:
通知の受信日時・経路:
通知が示す変更日時:
変更の種類（追加／削除／解除／回復先／コード再生成）:
追加・削除された認証方法:
本人の心当たり:
正規の変更チケット・承認者:
監査ログ上の実行者・結果:
サインイン結果・端末・利用アプリ:
不明なセッション・端末:
回復先・OAuth・メール設定・権限の変更:
実施した失効・無効化・再登録:
保全したログと対象期間:
担当者・エスカレーション先:
利用者への連絡内容:
次回確認日時:

個人利用でも、変更日時と実施した対応を残すと、後から届いたログイン通知やデータ変更と照合できます。組織ではインシデント証跡保全の初動対応に沿い、原本、取得時刻、取得者を記録します。

判断基準：危険度とエスカレーション条件

優先度	条件	推奨対応
緊急	MFA解除・不明な認証方法追加に加え、回復先変更、管理者権限付与、メール転送、データ操作がある	アカウント侵害としてセッションと認証方法を失効し、CSIRT・責任者へ即時報告する
緊急	管理者、IdP、メール、経理、GitHub、クラウド管理アカウントで本人がログインできない	公式回復経路と緊急アクセス手順へ移り、関連アカウントへの波及を確認する
高	心当たりのない認証方法変更はあるが、後続操作をまだ確認できない	変更を正規とみなさず、封じ込めとログ確認を並行する
中	管理者による正規リセットだが、チケット、承認者、本人確認記録が不足している	利用を継続する前に記録と再登録手順を補完する
低	本人の操作と時刻・端末・変更内容が一致し、他の不審イベントがない	根拠を記録し、古い方法と回復手段を整理する

優先度は、通知の文面ではなく、変更主体、アカウントの権限、回復先の支配、既存セッション、後続操作、他ユーザーへの波及で決めます。高権限アカウントは、後続操作が見つかるまで待たずにエスカレーションします。

よくある誤解

「MFAを削除すれば、第三者は追い出せる」

不審な認証方法を削除しても、すでに発行されたセッションやOAuthトークンが残る場合があります。認証方法、パスワード、セッション、連携アプリを別々に確認します。

「パスワードを変更すれば、すべてのセッションが終わる」

失効動作はサービスごとに異なります。全セッション終了、端末削除、アプリ独自セッションの確認を明示的に行います。

「管理者がリセットしたならセキュリティ問題ではない」

正規リセットでも、本人確認や承認記録がなければ同じ経路が悪用される可能性があります。管理者の操作だから除外するのではなく、チケットと監査ログで正当性を確認します。

「MFAと2段階認証は常に同じ意味」

厳密には、MFAは異なる種類の認証要素を組み合わせる方式です。サービス上の「2段階認証」は同じ種類の要素を含む場合もあります。ただし初動では名称の違いより、どの認証方法が追加・削除され、誰が使える状態かを確認することが重要です。

「バックアップ方法は多いほど安全」

回復手段は可用性を高めますが、古い電話番号や管理されていないメールが残ると別の入口になります。NISTは複数の通知先・認証手段を維持する考え方を示していますが、それぞれを最新かつ管理下に保つ必要があります。

公式情報・参考情報

NIST SP 800-63B: Authentication and Authenticator Management - 認証器の追加・無効化、アカウント回復、独立した通知、セッション管理に関する現行要件。
Microsoft Entra: Security operations for privileged accounts - 特権アカウントの認証方法変更を高重要度の監視対象として扱う公式ガイド。
Microsoft Entra: Learn about the audit logs - 変更主体、対象、結果などを監査ログで確認する公式ガイド。
Microsoft Entra: Revoke user access in an emergency - IdPのトークンとアプリ独自セッションを分けて失効する必要性を確認できる公式説明。
Google Account Help: Make your account more secure - 回復先、2段階認証、パスキー、Security Checkupに関する公式手順。
GitHub Docs: Reviewing your security log - 2FA、パスキー、OAuth、アカウント設定のイベント確認・出力に関する公式ガイド。
GitHub Docs: Changing your two-factor authentication method - 2FA方式の変更、追加方式、回復手段に関する公式手順。

身に覚えのないMFA変更・解除通知の初動対応：認証方法を守る確認チェックリスト

冒頭要約

MFA変更・解除通知とは

読者別の影響